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PREFACE 


In  1972  the  National  Bureau  of  Standards  (NBS)  and  the  Association 
for  Computing  Machinery  (ACM)  initiated  a  series  of  workshops  and 
conferences  which  they  jointly  sponsored  and  which  treated  issues 
such  as  computer  security,  privacy,  and  data  base  systems.  The 
three  -day  Workshop,  DATA  BASE  DIRECTIONS--The  Conversion 
Problem,  reported  herein  continues  that  series.  This  Workshop 
was  held  in  Fort  Lauderdale,  Florida,on  November  1-3,  1977,  and  is 
the  second  in  the  DATA  BASE  DIRECTIONS  series.  The  first,  DATA 
BASE  DIRECTIQNS--The  Next  Steps,  received  wide  circulation  and, 
in  addition  to  publication  by  NBS,  was  published  by  ACM's  Special 
Interest  Group  on  Management  of  Data  and  Special  Interest  Group  on 
Business  Data  Processing,  the  British  Computer  Society  in  Europe, 
and  excerpted  by  IEEE  and  Auerbach. 

The  purpose  of  the  latest  Workshop  was  to  bring  together  leading 
users,  managers,  designers,  impl ementors,  and  researchers  in 
database  systems  and  conversion  technology  in  order  to  provide 
useful  information  for  managers  on  the  possible  assistance 
database  management  systems  may  give  during  a  conversion 
resulting  from  an  externally  imposed  system  change. 

We  gratefully  acknowledge  the  assistance  of  all  those  who  made  the 
Workshop's  results  possible. 


S 

DWector,  Cerrter  for  Programming 

Science  and  Technology 

Institute  for  Computer  Sciences  and 

Technology 
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A  MANAGEMENT  OVERVIEW 


To  a  manager,  conversion  answers  the  question,  "How  do  I 
preserve  my  investment  in  existing  data  and  programs  in  the  face 
of  inevitable  changes?"  Selection  of  conversion  as  a  solution 
depends  directly  on  issues  of  cost,  feasibility,  and  risk.  Since 
change  is  inevitable,  prudent  managers  must  consider 
preparations  that  ease  inevitable  conversions.  How  does  a 
manager  choose  a  course  of  action? 

When  Mayford  Roark,  Executive  Director  of  Systems  for  the 
Ford  Motor  Company,  and  Keynoter  of  the  Workshop,  sought  an 
analogue  for  examining  DBMS  and  the  conversion  problem,  he  aptly 
selected  the  idea  of  "mapping  a  jungle."  Reporting  on  his 
experience,  he  noted  that  90%  of  his  computers  were  changed  within 
three  to  five  years  and  major  software  changes  from  the  vendor 
occurred  somewhere  between  five  and  ten  years  after  acquisition. 

These  forced  changes  coupled  with  the  organization's 
changing  requirements  led  Roark  to  a  basic  point:  "evolutionary 
change  is  the  natural  state  of  computer  systems."  In  short,  the 
ADPmanager's  continual  task  is  to  "manage  change." 

Roark's  managers  experienced  the  classic  benefits  of  DBMS: 
quicker  response  to  changing  requirements,  easier  new 
application  development,  and  new  capabilities  not  possible  in  the 
earlier  systems,  but  Roark  summarized  his  conversion  experience 
within  a  DSBMS  environment  in  this  way: 

.  hardware  changes  —  having  a  DBMS  was  a  moderate  to  major 
burden. 

.  software  changes  —  dependent  on  the  circumstances,  having 
a  DBMS  ranged  from  negligible  impact  to  am  a  j  or  burden. 

.  evolutionary  application  change  —  havi  ng  a  DBMS  was  a 
moderate  boon.  It  proved  effective,  but  very  expensive. 

Considering  even  the  conversion  to  a  DBMS,  Roark  scores  this 
process  a  moderate  burden  because  of  the  risks  and  costs 
associated  with  DBMS. 
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He  emphasized  this  point  by  describing  the  major  DBMS 
need  as  "easy-to-use,  easy-to-apply ,  and  inexpensive 
approaches  for  upgrading"  two  decades  of  computer  files  to  a 
data  base  environment. 

Given  this  charge, how  did  the  workshop  respond? 

Consideration  of  the  conversion  to  a  DBMS  led  to 
several  specific  caveats  intended  to  control  the  risk 
inherent  in  such  a  step. 

Though  conversion  to  a  DBMS  requires  careful 
preplanning  and  may  not  be  appropriate  for  every 
application,  managers  should  consider  data  base 
technology  an  inevitable  development  thrusting 
itself  on  future  data  processing  installations.  A 
manager  will  have  no  choice  but  to  face  this 
decision  eventually. 

The  first  DBMS  application  can  make  or  break  the 
success  of  the  conversion.  The  new  system's  users 
must  have  a  receptive  disposition  which  results  only 
from  careful  preparation,  preplanning,  and  the 
application  of  basic  management  skills.  The  initial 
application  plays  an  important  tutorial  role  for 
everyone  in  the  organization  including  such  subtle 
1 essons  a  s : 

--whether  management  is  truly  committed  to  the  new 
system  by  supporting  it  with  adequate  resources, 
planning  for  the  continuous  support  of  the  system, 
and  applying  the  necessary  managerial  cross- 
department  discipline. 

--whether  the   installation  technical   staff   truly 

appreciates   user  needs,  can  adjust  to  user  changes, 

and  has  the  necessary  skills  and  backing  to  carry- 
off  the  task. 

--whether  any  of  the  DBMS  conversion  proponents 
have  accurate  estimates  of  the  costs,  the  proper 
tools  to  use,  and  a  feasible  conversion  plan 
expressed  in  terms  that  satisfy  a! 1  risk  sharers. 
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While  the  staff  must  know  the  new 
technology,  they  must  not  conclude  that  the 
new  technology  relieves  them  of  the  old 
project  management  controls  that  all  new 
systems  reauire.  Tight  planning,  management 
control,  cost  monitoring,  contingency 
approaches,  user  review,  and  step-wise 
justifications  must  be  used. 

No  "final  conversion"  ex i sts--pl anni ng  for 
the  next  one  begins  now!  Prepare  your 
system  to  permit  evolutionary  change  to 
enhanced  technology--!'  ncl  udi  nq  improvements 
to  DBMS. 


How  will  future  technology  help 
Hardware  development,  particularly  the  prol 
of  mini-  and  micro-computers,  networks,  a 
mass  storage,  will  increase  the  need  for  ge 
conversion  tools.  On  the  other  hand, 
hardware  costs  will  make  conversion  inc 
more  acceptable.  Additionally,  speci 
machines  which  promote  logical  level  in 
will  simplify  the  conversion  process, 
advances  in  improved  data  independence 
software  design  will  also  simplify  bu 
eliminate  the  conversion  problem.  Of 
concern  to  managers:  user  demand  for  seve 
models  will  continue. 
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In  the  next  five  years,  managers  can  expect  to 
see  more  operational  generalized  conversion  tools 
but  certainly  not  full  automation  of  the  process. 
Significantly,  standards  design  and  acceptance  by 
vendors  will  plan  a  major  role  in  the  success  of 
generalized  conversion  tools.  Commercially 
available  tools  for  data  base  conversion  seem  likely 
in  ten  years  but  the  conversion  of  application 
programs  is  not  likely  to  have  a  generalized 
solution  in  the  next  five  years. 

Standards  address  several  manager  needs  in  the 
conversion  process.  A  standard  DBMS  would 
considerably  ease  the  future  conversions  involving  a 
DBMS.  A  standard  data  dictionary/directory  would 
facilitate  all  conversions.  This  latter  point 
emphasizes  that  the  data  dictionary/directory  can 
stand  apart  from  data  base  systems  and.  therefore, 
can  assist  the  conversion  to  a  first  DBMS. 
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A  standard  data  interchange  format  would  ease 
considerably  the  loading  and  unloading  of  data  and 
thus  facilitate  the  development  of  generalized 
conversion  tools.  Manufacturer  acceptance  of  the 
standard  format,  would  permit  their  development  of 
convertors  from  the  standard  form  to  their  system,  a 
boon  to  managers  either  forced  to  or  desirous  of 
considering  a  different  system. 

Similarly,  standardization  of  the  terminology 
used  in  data  base  technology,  convergence  of 
existing  DBMS  to  using  common  functions,  and  use  by 
DBMS  of  a  micro-language  or  standard  set  of  atomic 
functions  would  assist  managers  in  dealing  with 
conversion  from  DBMS  to  DBMS. 

In  summary:  in  the  next  five  to  ten  years 
managers  must  depend  on  existing  good  management 
practices  rather  than  wait  for  automated  conversion 
tools.  Standards,.  as  a  management  exerted 
discipline,  will  facilitate  conversions  but  users 
can  expect  reluctant  acceptance  of  standards. 
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DATA  BASE  DIRECTIONS — 
The  Conversion  Problem 

John  L.  Berg,  Editor 


ABSTRACT 

What  information  can  help  a  manager  assess 
the  impact  a  conversion  will  have  on  a  data  base 
system,  and  of  what  aid  will  a  data  base  system  be 
during  a  conversion?  At  a  workshop  on  the  data 
base  conversion  problem  held  in  November  1977 
under  the  sponsorship  of  the  National  Bureau  of 
Standards  and  the  Association  for  Computing 
Machinery,  approximately  seventy-five  participants 
provided  the  decision  makers  with  useful  data. 

Patterned  after  the  earlier  Data  Base  Direc- 
tions workshop,  this  workshop,  Data  Base 
Directions — the  convers  ion  problem,  explores  data 
base  conversion  from  four  perspectives:  manage- 
ment, previous  experience,  standards,  and  system 
technology.  Each  perspective  was  covered  by  a 
workshop  panel  that  produced  a  report  included 
here. 

The  management  panel  gave  specific  direction 
on  such  topics  as  planning  for  data  base  conver- 
sions, impacts  on  the  EDP  organization  and  appli- 
cations, and  minimizing  the  impact  of  the  present 
and  future  conversions.  The  conversion  experience 
panel  drew  upon  ten  conversion  experiences  to  com- 
pile their  report  and  prepared  specific  checklists 
of  "do's  and  don'ts"  for  managers.  The  standards 
panel  provided  comments  on  standards  needed  to 
support  or  facilitate  conversions  and  the  system 
technology  panel  reports  comprehensively  on  the 
systems  and  tools  needed — with  strong  recommenda- 
tions on  future  research. 

Key  words:  Conversion;  Data  Base;  Data 
Description;  Data  Dictionary;  Data  Directory; 
DBMS;  Languages;  Data  Manipulation;  Query. 
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1.   INTRODUCTION 


Daniel  B.  Magraw 
GENERAL  CHAIRMAN 


Biographical  Sketch 

Daniel  B.  Magraw  is  Assistant  Commissioner, 
Department  of  Administration,  State  of  Minnesota. 
For  nearly  ten  years  he  has  been  responsible  for 
all  aspects  of  the  State  of  Minnesota  information 
systems  activities.  His  more  than  thirty  years' 
experience  in  systems  divides  almost  equally 
between  the  private  and  public  sectors. 


A  frequent  contributor 
activities,  he  was  one  of  the 
past  president  of  the  National 
State  Information  Systems.  He 
Systems  for  22  years  in  the 
Minnesota   Extension   Division 


to   professional 

founders  and  is  a 

Association   for 

taught  courses  in 

University   of 

and   he  has  been  a 


frequent  speaker  on  many  matters  relating  to 
information  systems  and  has  been  deeply  involved 
with  both  Federal  and  state  data  security  and 
privacy  legislation. 


He  was  keynote  speaker  at  the  1975  Data 
Directions  Conference. 
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1.1   THE  FIRST  DATA  BASE  DIRECTIONS  WORKSHOP 

In  late  October,  1975,  a  Workshop  entitled  "Data  Base 
Directions:  The  Next  Steps"  was  held  in  Fort  Lauderdale,  Florida. 
Resulting  from  a  proposal  brought  to  Seymour  Jeffery  at  the 
National  Bureau  of  Standards  by  Richard  Canning  and  Jack  Minker, 
the  workshop  was  sponsored  jointly  by  the  Association  for 
Computing  Machinery  and  NBS.  The  product  of  the  intensive  two  and 
a  half  day  effort  was  a  series  of  panel  reports  which,  as 
subsequently  edited,  were  issued  under  the  title  of  the  workshop 
as  NBS  Special  Publication  451. 
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As  early  as  December,  1975,  suggestions  were  made  to 
ACM  and  NBS  concerning  the  desirability  of  one  or  more 
future  conferences  on  the  same  general  topic.  These 
suggestions  were  based  on  the  belief  that  data  base  systems 
will  grow  increasingly  in  importance  and  pervasiveness  and 
were  supported  by  perceptions,  even  prior  to  issuance  of  NBS 
SP  451,  that  the  workshop  had  more  than  met  expectations. 

The  report  was  issued  in  1976;  it  was  generally  thought 
to  be  a  valuable  contribution  to  several  audiences  including 
top  management,  EDP  management,  data  base  managers,  and  the 
industry".  It  has  had  an  unusually  wide  circulation  for 
reports  of  this  nature. 


1.2   PLANNING  FOR  SECOND  CONFERENCE 

In  February,  1977,  ACM  and  NBS  decided  in  favor  of  a 
second  data  base  workshop  and  invited  me  to  serve  as  General 
Chairman.  An  initial  planning  group  was  established 
consisting  of  Dick  Canning  and  Jack  Minker  representing  ACM, 
John  Berg  representing  NBS,  and  the  chairman.  The  planning 
group  entitled  the  Conference  "Data  Base  Directions  II--The 
Conversion  Problem." 

Four  working  panel  subjects  were  selected.  Panel 
chairmen  were  recruited  and  became  members  of  the  planning 
group.  Subject  matter  coverage  for  each  panel  was  specified 
by  the  planning  group.  Each  panel  chairman  then  selected 
members  of  his  working  panel.  In  addition,  the  planning 
group  specified  that  the  format  and  procedure  for  the 
workshop  should  follow  closely  that  of  the  first  workshop. 
As  in  the  1975  workshop,  attendance  was  by  invitation  only. 
Work  was  done  by  each  panel  prior  to  arriving  at  the 
work  shop  . 


1 .3   DATA  BASE  DIRECTIONS  II 

The  workshop  was  held  November  1-3,  1977,  in  Fort 
Lauderdale,  Florida.  There  were  approximately  75  in 
attendance.  Mayford  Roark,  Ford  Motor  Company,  gave  an 
excellent  keynote  address  in  plenary  session,  reproduced 
herein.  Final  instructions  were  given  as  to  objectives  of 
the  workshop,  and  all  panels  were  in  full  operation  by  10:30 
a.m.,  November  1.  From  then  until  the  closing  plenary 
session,  each  of  the  four  panels  met  separately  with  the 
ultimate  purpose,  of  developing  a  consensus  among  its  members 
on  which  to  base  the  panel  report. 
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Each  working  panel  chairman  was  expected  to  guide  the 
group  discussion  and  to  assure  preparation  of  a  good  rough 
draft  report  prior  to  the  closing  plenary  session.  Though 
each  panel  chairman  organized  his  panel  in  a  form  best  for 
his  subject,  each  followed  a  general  pattern.  A  recorder 
was  selected  from  among  each  panel's  members  to  maintain 
"minutes"  in  visual  form  on  flip  chart  sheets.  These  were 
displayed  so  that  the  principal  discussion  and  consensus 
points  were  visible. 

One  of  the  panels  had  done  extensive  drafting  of  report 
segments  prior  to  the  beginning  of  the  workshop.  Each  of 
the  other  three  accomplished  the  objective  of  rough  draft 
preparation  by  developing  detailed  outlines.  Portions  of 
the  outlines  were  assigned  to  individual  panel  members  or  to 
two  person  teams  for  draft  preparation.  When  time 
permitted,  drafts  were  reviewed  by  others  on  the  same  panel 
prior  to  their  incorporation  into  the  final  draft. 

Following  the  completion  of  the  workshop,  the  drafts 
were  put  into  "final"  form  and  circulated  to  panel  members 
for  final  comment  prior  to  submission  to  the  proceedings 
edi  tor . 

Communication  among  the  four  panels  was  maintained 
mainly  through  the  panel  chairmen  and  members  of  the 
planning  group  who  circulated  among  the  panels.  At  the 
closing  plenary  session,  each  working  panel  chairman 
presented  a  twenty  minute  summary  of  his  panel's  findings 
and  responded  to  Questions  or  comments  from  the  floor. 


1.4   CONCLUSION 


T 
perspe 
a  base 
unpara 
materi 
the  c 
It  is 
impact 
on  two 
attemp 
d  e  c  i  s  i 
II  ,  ho 
that  t 


he 
cti  v 

of 
llel 
al  v 
ount 
hope 
th 

mor 
ted 
on- 
weve 
hi  s 


mix  o 
es ,  ex 
knowl e 
ed.  T 
al ue  ,  e 
ry  car 
d  that' 
an  did 
e  years 
to  be  m 
makers . 
r ,  will 
documen 


f   P 

p  e  r  i  e 

dge 

he   o 

s  p  e  c  i 

ry  ing 

this 

Data 

of  e 

ore  d 

The 

be  d 

t  pro 


a  r  t  i  c  i  p 
nces ,  a 
in   d  a  t 
utput 
al ly  to 

respon 
p  u  b  1  i  c  a 

Base  D 
x  t  e  n  s  i  v 
i  r  e  c  t  a 

real  v 
i  r  e  c  1 1  y 
v  i  d  e  s  t 


ants 
nd  te 
a   ba 
from 

thos 
sibil 
tion 
i  r  e  c  t 
e  ex 
nd  po 
al  ue 

prop 
o  the 


with 
c  h  n  i  c  a  1 
se   syst 

that  g 
e  d  e  c  i  s 
i  ty  for 
can  have 
ions  I  b 
p  e  r  i  e  n  c  e 
i  n  t  e  d  in 
of  Data 
o  r  t  i  o  n  a  1 

several 


the 
expe 
ems 
roup 
ion- 
data 

an 
ecau 
an 

its 
Ba 

to 

cl  a 


i  r   d 
r  t  i  s  e 

that 
shou 
makers 

base 

even 
se  it 
d   bee 

a  d  v  i  c 
se  Di 
the  as 
sses  o 


iffe 
prov 

may 

Id  b 

ac 

f  utu 

gre 
i  s  b 
ause 
e  to 
rec  t 
si  st 
f  us 


ring 
ides 

be 
e  of 
ross 
res  . 
ater 
ased 

it 

the 

ions 

ance 

ers . 


-5 


EVOLUTION  IN  COMPUTER  SYSTEMS 

Mayford  L.  Roark 
KEYNOTER 


Biographical  Sketch 

Mayford  L.  Roark  is  Executive  Di 
Systems  for  the  Ford  Motor  Company  in 
Michigan.  He  has  been  in  charge  of  the 
systems  function  at  Ford  since  1965,  as 
Controller  and  later  as  Director  of  th 
Office  before  assuming  his  present  p 
1973.  He  joined  the  Ford  Division  of  F 
Company  in  1952  as  Senior  Financial  An 
managed  various  financial  departments  at 
1955-1965. 

Mr.  Roark  was  a  Budget  Examiner  at 
Bureau  of  the  Budget  from  1947 
Previously  he  was  with  the  U.S.  Weather 
the  Colorado  Department  of  Revenue. 
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the   U.S. 

to   1952. 
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He  studied  at  the  University  of  Colorado, 
receiving  the  B.A.  "Magna  Cum  Laude"  degree 
(Economics),  and  the  M.S.  (Public  Administration). 
He  is  a  member  of  Phi  Beta  Kappa. 


2.1   QUESTIONS 

When  I  was  asked  to  address  this  group,  with  its  theme 
of  "The  Conversion  Problem,"  I  felt  some  puzzlement  about 
the  thrust  of  the  meeting.  Was  there  a  concern  that  data 
base  systems  miqht  be  something  of  a  special  burden  for  the 
organization  faced  with  a  conversion  problem?  Or,  rather, 
was  there  the  hope  that  the  data  base  system  might  be 
something  like  "Seven  League  Boots,"  for  making  otherwise 
tough  conversions  into  happy  and  speedy  journeys?  Or,  was 
there  a  lingering  horror  that  the  data  base  systems 
themselves  might  turn  out  to  be  conversion  nightmares  as 
improved  DBMS  resources  become  available? 
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As  the  working  outlines  began  to  arrive  through  the 
mail,  it  became  clear  that  all  of  these  questions  were 
concerns.  As  Jim  Fry  s  statement  put  it,  "The  basic  problem 
we  are  addressing  is  the  need  to  migrate  data  and 
applications  due  to  the  introduction  of  new,  or  change  in 
^tpmc^T  .re;u1r?ments»  hardware,  and/or  software 
•un  1         short,  it  appears  that  your  intent  is  to  map  a 
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impressions.    As  you  survey  a  topic  in  depth,  "yoTmay  well 
conclude  that  some   of   these   were   inaccurate.    This   ha 
certainly   been   the 
detailed   surveys   re 
travelers. 


panels  by  offering  any  detailed  map  of  my  own.  Rather  as 
frequent  travel er  through  this  jungle,  my  traveler's  'note 
may  be  of  some  help  to  your  individual  survey  parties  M 
comments   will   take   the   form   of   generalizations    an 
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As   an   initial   generalization,   let   me 
conversion  problems  into  four  families  of  change 

Hardware  Changes, 

Software  Changes, 

Evolutionary  Application  Development, 

Migration  to  a  Mew  DBMS. 
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d  like  to  discuss  each  of  these  families  of 
problems,  and  to  relate  my  own  impressions  as  to 
ncy  of  occurrence  and  their  significance  with 
ata  base  management  systems.  In  an  effort  to  be 
as  possible,  I  will  try  to  rate  the  impact  of  a 
against  a  "BB  seal e"-- that ' s  shorthand  for 
If  a  DBMS,  in  my  view,  is  a  major  boon  or 
of  conversion  problem,  I  shall  score 
a  moderate  boon,  that  will  be  plus 
likely  to  be  a  burden  than  a  boon,  I 
1  or  minus  2.       Now  let  me  proceed  to 
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of  these  families  of  conversion  problems. 


2.2   HARDWARE  CHANGES 
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The  extent  of  conversion  trauma  from  a  hardware  upgrade 
depends  on  the  nature  of  the  change.  If  the  change  involves 
shifting  to  another  supplier,  an  event  that  occurred  in 
something  like  5  percent  of  our  hardware  changes,  the 
conversion  effort  can  be  an  extended  affair  requiring  a 
major  effort  over  a  period  of  a  year  or  more.  In  such 
cases,  a  DBMS  is  likely  to  be  something  of  a  burden.  In  all 
probability,  the  new  equipment  will  require  a  shift  to  a 
different  DBMS.  In  any  event,  the  logic  requiring 
conversion  will  be  somewhat  more  complex  and  difficult  to 
handle  if  a  DBMS  is  present. 

One  of  our  divisions  recently  completed  a  conversion 
from  Honeywell  to  Burroughs,  a  change  made  necessary  because 
of  reorganization  unrelated  to  the  system  function.  Some  of 
the  application  programs  to  be  converted  had  been  developed 
in  Honeywell's  IDS  environment;  they  were  converted  to 
Burroughs  DMS  II.  IDS  is  a  network  system;  DMS  II  is  a 
hierarchical  structure,  so  one  might  guess  that  we  would  have 
had  problems.  In  fact,  I  am  assured,  both  by  our  own  people 
and  by  the  Burroughs  conversion  team,  that  this  transition 
went  fairly  smoothly.  On  the  basis  of  that  once-in-a- 
lifetime  experience,  I  would  have  to  score  the  DBMS  in  this 
case  as  minus  1.  Perhaps  it  would  have  been  minus  2  if  the 
application  programs  involved  had  been  larger  and  more 
compl ex . 
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Hardware  conversion  can  also  be  a  serious  trauma  when 
migrating  to  new  products  of  an  incumbent  supplier 
Suppliers  do  present  us  with  new  families  of  hardware  from 
time  to  time  that  require  structural  changes  in  our 
application  programs  and  supportina  software.  "  Hopefully 
this  kind  of  change  will  be  less  frequent  in  the  future  than 
it  has  been  in  the  past.  Even  so,  I  suspect  we  are  likely 
to  be  faced  with  something  of  this  kind  e^ery  10  years  or 
so.  Already,  one  hears  strange  rumblings  about  the  kinds  of 
changes  likely  to  unfold  2  or  3  years  hence  in  a  new  product 
line  called  'The  New  Grad."  So  far,  DBMS  has  not  figured 
importantly  in  any  of  our  conversions  within  the  hardware 
products  of  a  given  supplier.  On  the  basis  of  guesswork  and 
a  skeptical  disposition,  I  would  have  to  assume  that  the 
presence  of  a  DBMS  for  a  major  hardware  family  transition 
would  be  similar  to  that  where  a  change  in  supplier  is 
involved,  possibly  minus  1  or  minus  2  on  the  BB  scorino 
scale.  3 

The  remaining  hardware  conversions,  which  represent  the 
vast  majority  of  all  hardware  upgrades,  involve  moving  up 
within  a  compatible  family  of  products  offered  by  a  single 
supplier.  In  these  cases,  DBMS  would  not  be  much  of  a 
factor,  so  we  might  score  its  presence  as  zero  on  the  BB 
scale. 


2.3   SOFTWARE  CHANGES 

Despite  IBM's  assurance  that  MVS  is  here  to   stay   our 
experience   would   suggest   that   we   can   look   for  "major" 
software  upgrades  or  enhancements  from  any  supplier  every      5 
or   10  years.    At  Ford,  we  are  somewhat  preoccupied  at  the 
moment  with  the  MVS  problem  at   our   large   data   center   in 
Dearborn.    The  completion  of  this  conversion  will  require  a 
major  effort  extending  over  a  two-year   period.    There  are 
three   substantial   groups  of  data  base  systems  that  will  be 
affected  by  the   conversion;   these   involve,   respectively 
IMS,   TOTAL,   and   SYSTEM  2000.   I  have  checked  with  each  of 
the  systems  groups  involved   to   see   how   they   assess   the 
impact   of   DBMS   at  this  point,  when  we  are  about  midway  in 
the  conversion  effort.   The  managers  working  with  IMS   agree 
that   its  presence  has  added  substantially  to  the  difficulty 
and  complexity  of  the  conversion   task--somethi ng   close   to 
twice   as   much  effort  as  would  have  been  involved  with  non- 
DBMS  applications.   The  IMS  conversion  involves  more  than   a 
new  operating   system,  however.   It  requires  the  transition 
to  a  new  DBMS  called   IMS-VS.    One   manager   sees   the   new 
package   as   offering  many  attractive  new  features.   Another 
manager   sees   no   incremental   benefits   at   all   for   his 
particular   applications;   but  he  has  no  choice,  his  present 
IMS  software  will  not  be  supported  under  MVS. 
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The  managers  using  TOTAL  and  SYSTEM  2000  see  no  special 
conversion  problem  at  all  in  going  to  MVS. 

This  sampling  of  experience  adds  up  to  a  very  mixed 
bag.  As  the  warnings  say  about  some  drugs,  a  major  software 
conversion  "may  be  hazardous  to  your  heal th"--but  again,  it 
may  not.  I  think  we  have  to  score  the  presence  of  a  DBMS  in 
such  a  situation  with  a  range  from  0  to  minus  2  on  the  BB 
seal e . 

We  do  have  numerous  other  software  changes,  of  course, 
on  an  almost  continuous  basis--new  releases  to  old  operating 
systems,  new  software  packages  to  handle  new  functions,  and 
the  like.  There  is  nothing  in  our  experience  to  indicate 
that  DBMS  is  much  a  factor  one  way  or  another  in  these  minor 
changes . 


2.4   EVOLUTIONARY  APPLICATION  DEVELOPMENT 


Now  we  move  into  the 
function  is  all  about,  and 


terri  tory   of 
what  DBMS  al so 


what   the   systems 
is  all  about. 


Before  getting  into  the  particulars  about  this  family 
of  change,  we  ought  to  be  clear  on  one  central  point. 
"Evolutionary  change"  is  the  natural  state  of  computer 
systems,  just  as  it  is  for  biological  systems.  Perhaps  I 
should  not  push  this  analogy  too  far  because  there  is  one 
dramatic  difference  —  evolutionary  change  works  more  rapidly 
in  computer  systems,  where  even  5  years  can  produce  dramatic 
changes  in  structure,  outputs,  and  even  objectives. 


During  the  past  5  years,   the   workload   at 
computer   centers   at   Ford   has  been  growing  at 
percent  annually.   I  might  explain  here  that  we 
measure   w6rkload   in   BIPS    (Billions   of 
Processed)  for  purposes  of  capacity  planning, 
say   that  growth  has  been  close  to  20  percent  a 
that  the  BIPS  have  been   growing   at   close   to 
annual ly . 


our   major 

close  to  20 

attempt   to 

Instructions 

So,   when   I 

year,  I  mean 

20   percent 


As  best  as  I  can   judge,   about 
results   from   new   applications   and 
adaptations  of  existing  applications. 


hal f   of   thi  s   growth 
about   hal f   from  new 


The  new  adaptations,  which  are  often  described  by  the 
rather  condescending  term  "maintenance,"  include  a  lot  of 
things.  One  is  simply  the  effect  of  volume.  If  we  sell 
more  cars,  other  things  equal,  we  will  process  more  BIPS. 
Another  is  changing  requirements.  In  our  industry,  every 
model  yedr  is,  in  a  sense,  a  new  game.  The  products  may 
change,  terminologies  may  change,  and  data  requirements   may 
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change.  One  of  the  biggest  sources  of  changing  requirements 
in  the  automotive  industry  is  government  regulation.  The 
work  of  the  regulators  never  ceases,  nor  does  the  growth  in 
requirements  for  additional  data  elements  in  the  burgeoning 
computer  records  that  we  must  maintain  as  evidence  of 
compliance  with  all  sorts  of  directives  from  Washington 


Some  of  these  changing  requirements  are  massive 
like   OSHA   regulations   or   like   corporate   fuel 
standards.    Others   seem   almost   trivial   until 


things 
economy 
,  they  are 

examined  in  the  context  of  required  changes  in  computer 
files.  The  industry  is  currently  being  asked  to  adopt  as  an 
international  standard  a  16-character  vehicle  identification 
number.  Our  existing  identification  numbers,  with  11 
characters,  turn  up  in  more  than  50  separate  computer  files 
in  North  America  alone.  The  cost  of  converting  these  files 
and  their  related  application  programs  to  the 
international  standard  is  estimated  at  $3  million. 


new 


In  all  fairness,  the  government  is  not  the  only  source 
of  changing  requirements,  our  engineers  and  product  planners 
are  pretty  good  changers  themselves.  Our  service  parts 
files  include  roughly  twice  as  many  parts  today  as  10  years 
ago,  when  our  basic  inventory  control  system  was  developed. 
Our  organization  people  contribute  more  than  a  fair  share  of 
changing  reaui rements .  Every  time  there  is  a  corporate 
reorganization,  we  find  it  necessary  to  go  through  a 
restructuring  of  the  hundreds,  or  even  thousands,  of 
computer  files  and  application  programs  that  are  affected  by 
the  real ignment . 

And  even  systems  people  are  contributors  to  the 
evolutionary  process,  only  we  usually  call  the  changes 
efficiency  improvements."  Almost  e\/ery  systems  activity 
has  its  own  more  or  less  continuous  effort  aimed  at  cleaning 
up  programs  that  run  inefficiently,  that  are  hard  to 
maintain,  or  that  otherwise  need  overhaul. 

To  make  another  sweeping  generalization,  I  would  judge 
that  each  of  our  systems  activities  annually  rewrites 
somewhere  between  5  percent  and  25  percent  of  its 
accumul a  ted  code  . 

What  a  fantastic  opportunity  for  data  base  management 
systems!  I  would  score  the  DBMS  impact  on  this  area  of 
evolutionary  application  development  as  plus  2  and  proceed 
to  the  next  topic  except  for  one  problem.  The  DBMS  benefits 
can  be  extremely  difficult  to  realize  in  practice,  and  the 
price  of  the  cure  is  sometimes  worse  than  the  pain  of  the 
ailment. 
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This  sort   of   overhead   can 


Several  years  ago,  another 
large-scale  data  base  system 
file  requirements  were  required 
requirements  in  such  a  case 
based  on  any  prior  experience, 
mean  a  loss  in  processing  productivity,  something  that  has 
to  be  weighed  against  any  benefits  in  programming 
productivity. 

The  best  score  I  can   give   DBMS,   therefore,   for   its 
impact   on  "evolutionary  application  development"  is  plus  1. 


It   sometimes 
expensive. 


works   well,   but   it   can   also   be   awfully 


Somewhere  in  the  deliberation  of  this  "or  related 
groups,"  there  ought  to  be  some  consideration  of  what  can  be 
done  to  simplify  DBMS  technolgy.  If  this  is  not  possible, 
perhaps  there  could  be  some  guides  or  standards  to  protect 
the  systems  designer  with  a  modest  problem  from  unwittingly 
stumbling  into  a  huge  solution  out  of  all  proportion  to  his 
need.  Sometime  in  the  future,  I  would  like  to  go  through  an 
exercise  like  this  again  and  conclude,  without  any 
reservation,  that  DBMS  is  an  unqualified  boon  for  the 
evolving  system  regardless  of  its  size  and  complexity.  We 
are    still  in  the  very    early  stages  of  DBMS  art. 


2.5   MIGRATION  TO  A  NEW  DBMS 

I  have  saved  this  family  of  conversion  problems  until 
last.  In  a  sense,  it  overlaps  all  three  of  the  categories  I 
discussed  earlier.  Migration  to  a  new  DBMS  may  be  prompted 
by  a  change  of  hardware;  it  may  be  forced  by  a  change  of 
software;  or  it  may  be  undertaken  with  a  view  to  realizing 
the  benefits  we  discussed  under  "evolutionary  applications 
development."  Still,  the  migration  to  a  new  DBMS  is  a  major 
event  that  deserves  consideration  in  its  own  right,  whether 
the  migration  is  from  a  non-DBMS  environment  or  is  the  rare 
change  from  one  DBMS  to  another. 
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There  is  a  logical  inconsistency  in  assigning  any 
rating  at  all  to  this  family  of  conversion  problems.  It  is 
like  asking,  "What  impact  does  DBMS  have  upon  itself?"  Yet, 
at  the  risk  of  sounding  completely  illogical,  I  am  aoing  to 
assign  a  BB  rating  of  minus  1  to  this  category  of  conversion 
problems  on  the  ground  that  a  DBMS  is  a  high-risk 
undertaking  entirely  apart  from  whether  it  is  related  to 
changes  in  hardware,  software,  or  applications. 

Moving  to  a  new  DBMS  is  not  unlike  the  process  of 
getting  married,  it  takes  a  lot  of  desire,  commitment, 
sacrifice,  and  investment.  It  involves  moving  to  a  wholly 
new  lifestyle.  Once  there,  the  return  to  the  old  lifestyle 
may  be  difficult  or  impossible  without  wrenching  adjustment 
probl ems . 
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These,  then,  are  the  major  problems  to  be  found  in  this 
jungle  of  systems  conversions.  To  summarize,  my  BB  scorings 
have  suggested  that  a  DBMS  can  constitute  a  moderate-to- 
heavy  burden  for  major  hardware  conversions  and  major 
software  conversions.  The  presence  or  availability  of  DBMS, 
however,   can   be  a  moderate- to-strong  boon  for  evolutionary 
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application  development.  Finally,  the  migration  to  a  DBMS 
system  can  be  a  long  and  tedious  journey,  especially  where 
existing  systems  of  great  size  and  complexity  are  involved. 

DBMS',  in  short,  still  offers  attractive  visions  of  a 
world  in  which  systems  might  respond  quickly  to  changing 
requirements,  in  which  new  creative  applications  might  be 
easily  spawned  from  existing  data  files,  and  where  data 
bases, in  the  words  of  Dan  Magraw  at  the  earlier  conference 
of  two  years  ago,  can  "move  the  DBM's  into  the  area  of 
decision  making." 

These  visions  ought  not  to  be  taken  lightly.  In 
preparing  for  this  meeting,  I  checked  back  with  our  managers 
who  have  been  in  the  DBMS  mode  for  5  years  or  more.  What 
benefits  did  they  really  get?  Their  consensus  might  be 
summarized  as  follows: 

1.  They,  indeed,  have  been  able  to  respond  more  quickly 
to  changing  requirements,  although  not  always  as 
easily  as  they  once  hoped. 

2.  New  applications  development  has  been  easier.  The 
managers  see  a  productivity  improvement  factor  in  a 
range  of  10  percent  to  20  percent. 

3.  Most  important,  the  managers  believe  they  have 
capabilities  that  previously  did  not  exist  at  all. 

Let  me  expand  on  these  capabilities  for  a  moment. 
Those  50,000  computer  programs  I  mentioned  are  a  long-time 
accumulation  in  response  to  numerous  problems  and 
opportunities  that  were  perceived  by  our  division  and  staffs 
over  a  period  of  two  decades. 
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As  functional  entities  for  the  purposes  they  were  first 
created,  these  old  programs  may  serve  well.  Even  where  we 
want  to  launch  a  new  application  that  will  need  to  draw  on 
the   data   in   these  files,  the  problem  is  not  overwhelming. 
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We  can,  and  do,  write  programs  to  get 
files,  wherever  they  exist. 


at   the   needed   data 


But  suppose  we  do  not  want  a  new  system.  All  we  want 
is  an  in-depth  analysis  of  a  difficult  problem  on  which  5  or 
10  different  files  have  something  useful  to  say.  This  is  a 
sort  of  problem  that  gives  computer  people  a  bad  reputation 
as  being  slow -moving  and  unresponsive.  It  can  be  extremely 
difficult  to  extract  data  from  5  or  10  different  sources, 
all  with  different  maintenance  cycles  and  data  control 
procedures,  and  produce  anything  but  a  mess. 

We  do  a  lot  of  computer-based  analysis  at  Ford  because 
we  have  found  that  the  data  resources  in  our  computer  files 
can  open  up  all  sorts  of  insights  and  understanding  that 
would  otherwise  be  lost.  I  wish  we  could  do  even  more,  but 
this  form  of  analysis  can  be  very  time  consuming  and 
frustrating  in  the  non-DBMS  environment.  We  have  been 
working  on  one  such  exercise  involving  non-DBMS  file  sources 
for  more  than  three  months,  all  because  of  the  relative 
inaccessibility  of  data.  Last  week  we  decided  to  skip  a 
promising  analysis  altogether  because  it  would  have  taken 
more  than  a  month  to  extract  and  organize  the  needed  data 
from  a  variety  of  source  files. 

So,  when  our  managers  talk  about  new  capabilities  from 

DBMS,   they  are      talking   about   one  of  the  computer's  most 

important   potenti al s--the   power   to   carry   analysis  to 
entirely  new  levels  of  understanding. 

The  benefits  cited  by  our  managers  are  impressive 
testimonials.  Why,  then,  has  the  data  processing  world  been 
so  slow  in  converting  to  DBMS?  I  have  seen  no  studies  that 
would  provide  an  accurate  measure  as  to  the  proportion  of 
data  processing  oriented  to  DBMS.  In  the  absence  of  any 
sure  data,  I  am  going  to  offer  the  opinion  that  the 
proportion  is  no  greater  than  10  percent  to  20  percent. 

I  have  never  expected  that  all  computer  systems  would, 
or  should,  move  to  DBMS.  In  the  early  Seventies,  however, 
as  we  first  began  to  realize  the  potential  of  this 
technology,  most  of  us,  even  the  conservatives  I  believe, 
would  have  expected  that  something  approaching  half  of  all 
computer  files  would  acquire  a  DBMS  format  by  the  end  of 
1977.  Even  at  Ford,  where  I  believe  the  impact  of  DBMS  has 
probably  been  greater  than  average,  the  progress  has  seemed 
slower  than  I  would  have  expected.  This  painfully  slow 
progress  points  up  perhaps  the  greatest  conversion  problem 
of  all--how  can  we  move  to  a  DBMS  environment  with  existing 
systems? 
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Most  of  our  DBMS  user  divisions  made  their  first  moves 
to  data  base  at  least  five  years  ago.  A  couple  of  these 
divisions  went  through  a  conversion  trauma,  eventually 
recovered,  and  never  undertook  a  subsequent  DBMS  project. 
Once  was  enough,  they  concluded. 

The  other  divisions  have  continued  to  extend  their  data 
bases  in  areas  of  new  systems  development.  But,  this  leaves 
a  very  large  accumulation  of  computer  files  more  or  less 
untouched  by  the  new  technology.  One  manager,  possibly  our 
most  enthusiastic  data  base  advocate,  believes  that  about  40 
percent  of  his  divisional  data  is  now  in  DBMS  format  after 
some  five  years  of  development.  He  guesses  that  this  figure 
may  reach  70  to  80  percent  in  another  five  years. 


We  have  still  another  group 
maintenance  workload  who  have 
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elected  not  to 
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The  problem  is  not  unlike  that  of  our  Detroit  skyline. 
We  recently  completed  a  magnificent  new  Renaissance  Center 
along  the  riverfront,  with  some  of  the  most  beautiful  hotel 
and  office  structures  to  be  found  anywhere.  This  is 
exciting,  but  there  is  still  a  long  way  to  go  to  bring  the 
rest  of  the  city  up  to  Renaissance  Center  standards.  The 
accumulation  of  history  is  still  a  huge  obstacle  to  those 
who  want  the  best  of  things  right  now.  Omar  Khayyam,  who 
summed  up  so  many  things  in  language  that  a  sophomore  can 
understand,  expressed  this  frustration  perfectly: 


...  could  thou  and  I  with 
grasp  this  Sorry  Scheme  of 


To 

Woul d  we 
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nearer  the  Heart's  desire! 


All  of  us,  however,  have  to  find  ways  to  working  with 
what  we  have  inherited.  We  might  all  wish  we  could  somehow 
get  rid  of  the  old  mess  and  start  all  over  again. 
Unfortunately,  that  old  mess  represents  an  investment  in  the 
hundreds  of  millions  of  dollars  for  my  company  and  in  many 
tens  of  billions  of  dollars  for  all  of  us  collectively. 

One  of  our  divisions  several  years  ago  tackled  this 
rebuilding  problem  in  what  seemed  to  me  an  innovative  kind 
of  way.  This  division  had  identified  15  overlapping  files 
that  had  evolved  over  the  years,  with  inventories  and  other 
data  related  to  parts.  As  might  be  expected,  there  was  much 
redundancy,  and  it  was  difficult  to  reconcile  one  file  to 
another.  A  complete  overhaul  of  the  applications  programs 
did  not  seem  feasible,  but  the  division  hit  on  the  idea  of  a 
DBMS  master  file  to  serve  as  a  sort  of  front   end   to   these 
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application  programs.  There  was   a   saving   of  more   than 

$100,000   annually   in  data  preparation   and  data  control. 

This  limited  effort   brought  the   division   into   the   DBMS 

environment   and   laid  the  basis   for   solid   evolutionary 

development,  including  subsequent  application   revisions   to 

exploit   more    fully  the  potential   of   the   data   base 
environment. 

If  there  is  one  thing  I  would  particularly  want  to  see 
come  out  of  this  conference,  then,  it  would  be  some  easy- 
to-use,  easy-to-apply ,  and  inexpensive  approaches  for 
upgrading  this  great  accumulation  of  computer  files  we  have 
all  been  working  on  for  the  last  two  decades  or  so.  We  have 
all  had  tantalizing  but  too-brief  experiences  with  data 
bases  as  they  can  be.  The  question  before  us  now  is,  what 
can  we  do  to  make  those  benefits  available  wherever  we  need 
them? 

Where  does  an  organization  with  an  accumulation  of 
1,500  to  3,000  programs  begin,  without  going  out  of  business 
for  a  year  or  two?  What  tools  can  it  use  to  map  out  its 
data  resources?  How  can  it  go  about  restructuring  these 
files  without  scrapping  its  investment  in  application 
programs?  And,  even  if  the  files  can  be  rebuilt,  what  about 
the  necessary  remodeling  of  the  interface  points  within  the 
old  programs?  I  hear  that  some  of  you  came  up  with  answers 
to  these  questions.  Perhaps  you  can  point  the  way  to  this 
new  data-rational  world  we  all  seek. 

The  realization  of  this  promise  is  still  a  long  way 
off.  The  real  world  of  tomorrow  will  come  when  the  DBMS  can 
contribute  to  the  evolutionary  process  of  applications 
development  and  to  the  full  analytical  use  of  computer 
resources,  without  exacting  an  extortionate  price;  when  the 
DBMS  can  aid  in  the  evolutionary  process  of  hardware  and 
software  change;  and  when  the  decision  to  go  to  a  DBMS  is  no 
longer  a  high  risk  affair  requiring  an  all-out  commitment 
through  one  of  the  most  difficult  conversion  problems  to  be 
found  in  systems. 

I  have  no  doubt  that  something  \/ery  much  like  this 
world  of  tomorrow  will  appear  one  of  these  days,  in  great 
part  because  groups  like  this  one  pressed  on  relentlessly  in 
the  definition  of  problems  and  the  search  for  creative 
solutions. 
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3.1   OVERVIEW 

"Assimilation  of  computer  technology  into  organizations 
is  a  process  that  has  unique  characteristics  which 
management  does  not  have  a  substantial  base  of 
experience  to  draw  upon  for  guidance.  Perhaps  the  most 
important  unique  characteristic  is  the  pace  of 
penetration  of  the  technology  in  the  operations  and 
conventional  information  systems."  [Richard  L.  Nolan, 
"Thoughts  About  the  Fifth  Staae,"  Data  Base  ,  Fall 
1975.] 

The  pace  of  the  assimilation  of  computer  technology 
into  the  data  processing  organization  is  represented  by  the 
S-shaped  "Data  Processing  Learning  Curve." 

The  Data  Processing  Learning  Curve  is  approximated  by 
the  growth  of  the  data  processing  budget  and  reflects  the 
staged  evolution  of  the  data  processing  environment  along 
four  growth  processes: 


Growth  process 
programs 


#1_,.  The  po  rtf  ol  io  of  computer 
The  programs  and  procedures  which  are 
organization  in  its  business  activities.    The 


appl i cat  ions . 


used by   the 
Appl i cat  ions 

Portfolio   represents  the  cumulative  end  product  of  the  data 
processing  organization. 


Growth  process  #_2  .  The  data  processing  organization  and 
technical  capabi 1 i  ties  .  ~  The  organization  structures  and 
technical  c  a  p  a  b  i 1 i  t  i  e  s  found  within  the  data  processing 
department  which  are  required  to  develop  and  operate 
application  systems.   These  include: 

Data  Processing  Management  Structure 

Hardware  and  Software  Resources 

Systems  Development  and  Operations  Organizations 

Growth  process  #_3  .  Data  processing  pi  a  n  n  i  n  g  and  ma  nagement 
control  systems .  The  set  of  organization  practices  used  to 
direct,  coordinate  and  control  those  involved  in  the 
development  and  operation  of  application  systems,  including: 

Data  Processing  Planning 

Project  Management 

Top  Management  Steering  Committees 
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Chargeout 

Performance    Measurement 


ASSIMILATION  OF  COMPUTER  TECHNOLOGY  OCCURS 
IN  FOUR  STAGES 


o 
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Control 
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Figure    2-1 
Process! nq    Learn  i  n  a    Curve. 


Growth  process  #4_.  The  user.  The  members  of  line  and  staff 
departments  who  must  use  the  applications  systems  in  order 
to    perform    their    jobs. 

The  nature  of  Data  Base  Management  Systems  (DBMS) 
dictates  that  they  interface  with  each  of  the  four  growth 
areas.  First,  the  DBMS  acts  as  the  data  manager  for  all 
types    of   application    systems.      Second,    the   DBMS    introduces    a 
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technology   to   be 


ne   management   considerations 
be   summarized   into   four   key 


conversions, 
identified  by  the  panel  can 
concepts : 


Sfy^I  "-^.CONVIimOM  ARE   A   HATTER   OF 


Conversion  from  a  non-data 
environment  is  a  part  of 
data  processing   within   an 


matured   and 
is   typically 


base   to   a   data   base 
the  natural  evolution  of 

Processing    department   ^icT^f1'0"  *    A   data 
progressed  to  a  Stage  III  environment 

toCresDondthtohL9hhma1ntenanCe  C0StS  and  an  ^abiTity 
io  respond  to  ad    hoc   inquiries   and   reouests   fmm 

user   management   for   intenrated   reports    This 

parent  "tV*"*',    f0rCeS   the   data   J'ocesI  g 

rIs?ruc?urP  tL  *  T1  °l •  data   base   technology   to 
restructure  the  applications   portfolio 

words,   conversion  to  a  DBMS 

of  how  soon  the  data  base  environment  shouM  t.pain 

to   be   constructed,    not  whether  h  Ja   k 

environment  should  be '  impl  emented  "   dat*   baSe 


In   other 
is  primarily  a  question 


KEY   CONCEPT   #2:    CHOOSE 
APPLICA  I  IOM  CARFFIII  I  V 


IHE    DBMS    CONVERSION 


The  initial  application  used  fo 


r  conversion  to   data 


-22- 


base  technology  represents  an  important  learning 
experience  for  the  entire  organization.  As  such, 
the  initial  application  should: 

-be   a    non-trivial    application 

-demonstrate  the  "power"  of  the  DBMS  facilities 
-be  simple  to  avoid  overextension  caused  by 
attempting  to  do  too  much,  too  fast 

KEY  CONCEPT  #3:  TREAT  THE  INITIAL  AND  SUBSEQUENT 
DBMS  CONVERSIONS  SIMILAR  TO  OTHER  SYSTEMS  PROJECTS 
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.  KE_Y_  CONCEPT  #4 :  PLAN  AND  STRUCTURE  FOR  FUTURE  DBMS 
CONVERSIONS  NOW;  DBMS  CONVERSIONS  WILL  BE_  A  WAY;  OF 
rTFT 

Certainly,  once  a  DBMS  is  successfully  installed, 
the  conversion  of  applications  to  that  DBMS  will 
continue.  However,  the  mature  organization  should 
also  plan  on  converting  to  another  DBMS  at  some 
point  in  time.  The  second  DBMS  may  be  just  an 
enhanced  version  of  the  first  DBMS,  or  it  may  be  a 
totally  new  software  package.  In  either  case,  it  is 
certain  that  a  mature  data  processing  organization 
will  want  to  take  advantage  of  new  DBMS  facilities 
and  efficiencies;  therefore,  DBMS  conversions  will 
become  a  way  of  1 i  f e  . 

To  prepare  for  these  continued  conversions,  the  data 
processing  organization  can  take  several  steps  to  minimize 
their  impact: 

minimize  the  application  system  processing  logic, 
program  code  and  data  base  design  dependencies  on 
the  features  of  a  particular  DBMS 
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.   institutionalize  the  Data  Administration  function 

.   fully  document  all  business  system  functions  on   an 
integrated  dictionary 


Es 
as 


The  overall  DBMS  conversion  philosophy  developed  by 
follows"9  Management  Objectives  panel  can  be  summari 


the 
zed 


Appreciate  the  technology,  but  recognize  that  DBMS 
conversion  j_s  a  management  problem: — — —  H£1^- 

The  panel  approached  the  topic  of  data  base  conversion 
in  a  chronological  manner.  As  such,  the  following  sections 
thP  ?!:?anize?  ^  reflect  management  considerations  du  ?nq 
the  life-cycle  of  data  base  conversion  efforts: 

•  CONVERSION  TO  A  DATA  BASE  ENVIRONMENT 

•  MINIMIZING  THE  IMPACT  OF  FUTURE  CONVERSIONS 
.   CONVERSION  FROM  ONE  DBMS  TO  ANOTHER  DBMS 

3.2   CONVERSION  TO  A  DATA  BASE  ENVIRONMENT 

A  certain  level  of  maturity  is  necessary  before 
conversion  to  a  data  base  environment  is  feasible  In 
general,  data  base  technology  is  not   appropriate   for   dat, 


conversi on . 


Thnn,!?llow1n9  sectl'°ns  discuss  the  impact  of  con 
to  a  DBMS  on  the  four  data  processing  growth  pro 
namel y :  3  b      v    u 


versi on 
cesses , 


Applications  Portfolio 

Data  Processing  Organization 

User  Awareness 

.   Data   Processing   Planning   and   Management   Control 
Sy stems 
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3.2.1  Impact  On  the  Application  P 
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Approaches  To  A  p  p 1 i  c  a  t  i  o  n  Conversion 


Two 


basic 


approaches  exist  for  conversion  of  the  application  portfolio 
to  a  data  base  environment:  revol utionary  and  evolutionary. 
Actually,  these  two  approaches  represent  opposite  ends  of  a 
continuum  of  approaches.  No  single  approach  is  universally 
best.  In  fact,  more  than  one  approach  may  be  operable 
within  a  given  conversion;  i.e.,  certain  application  systems 
may  be  converted  on  a  revolutionary  basis  while  other 
systems  are  converted  in  an  evolutionary  manner. 

In  the  revolutionary  approach  to  conversion,  sometimes 
called  resystemization ,  one  rewrites  and  restructures 
existing  appl i cation  systems  as  necessary  to  operate  under 
the  new  DBMS.  Generally,  one  should  avoid  exclusive  use  of 
this  approach  for  the  following  reasons: 


Risks  overextension  caused  by  attempting 
too  fast. 


too  much, 


Delays  in  one  sub-project  may  impact  others. 

Insufficient   resources  may   be   available   for 
developing  new  systems  during  the  conversion. 

At  the  opposite  extreme  of  the  revolutionary  approach 
is  the  evolutionary  approach  in  which  all  new  systems  are 
developed  under  the  new  environment.  Existing  systems  are 
not  converted  but  rather  are  replaced  at  the  end  of  their 
normal  life  cycle.  This  approach  reduces  the  risk  of 
overextension  and  the  impact  of  delays  in  sub-projects. 
However,  there  are  disadvantages  to  an  evolutionary 
approach: 
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Complex   interfaces   with   existing,    conventional 
systems  are  generally  entailed. 

Local   inefficiencies   and    redundancy   typically 
result. 


Current  organizational  deficiencies  and 
may  be  perpetuated. 


constraints 


Just  as   the   conversion 
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One  temporary  measure  that  may  be  employed  to  avoid  or 
postpone  conversion  is  to  extract  data  from  existing  master 
files  in  order  to  build  a  transient,  integrated  data  base. 
This  data  base  is  not  maintained  but  instead  is  recreated  on 
a  cyclic  basis.  The  data  base  is  used  for  cross-functional 
reporting  and  analysis.  This  approach  provides  early 
availability  of  c ross- functional  data  and  lends  itself  to  a 
specialized  interrogation  language.  At  the  same  time,  there 
are  certain  disadvantages  to  this  approach: 


Availability  of  data  is  achieved  at  the   expense 
redundancy  and  reloading. 


of 


Problems   of   timeliness   and   consistency   may   be 
created. 


Basic  application  limitations  are    perpetuated. 
Maintenance  Moratoriums.   There 


__  never   sufficient 

resources,   nor   is   it   appropriate,   to   permit   continued 
maintenance  and  enhancements  of  application   systems   during 
conversion   to   the   data   base  environment.   Moreover, 
requires  a  relatively  stationary  target.   Thus,  a 
on   maintenance    (or   more   accurately   on 
may  be  declared  during  conversion. 


the 

conversion 
moratori  urn 
enhancement) 
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A  common  device  for  invoking  moratoriums  is  a  steering 
or  priorities  committee.  Composed  of  data  processing  and 
user  management,  the  steering  committee  is  responsible  for 
approving  projects  and  establishing  priorities.  The 
steering  committee  does  not  manage,  nor  does  it  relieve 
management  of  its  business  responsibilities.  Rather,  it 
provides  a  forum  for  discussion  and  has  power  derived  from 
its  membership  and  sponsorship. 

Analysis  of  Opportunities.  Certain  application  systems 
indicate  bTtter  opportunities  for  conversion  than  others. 
The  following  types  of  applications  represent  good 
opportunities  for  conversion: 

An  application  system  using  many  different  master 
files  and/or  many  internal  sorts,  indicating  the 
need  to  represent  complex  data  structures  and  to 
support  multiple  paths  between  data. 

An  application  with  a  requirement  for  on-line 
inquiry  and/or  update  of  interrelated  data.  A  DBMS 
would  still  be  applicable,  although  not  required,  if 
the  data  were  not  interrelated. 

An  application  system  with  chronically  heavy 
maintenance  backlogs,  suggesting  redundant  data 
and/or  inflexibility  with  respect  to  its  data 
structures . 

An  application  system  requiring  a  broader  view  of 
data  (either  more  detail  or  greater  cross-functional 
breadth)  . 

An  application  which  crosses  functional  or 
organizational  boundaries  (e.g.,  project  control). 
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An  application  which  cannot  support 
needs . 


basic   business 


An  application  which  provides 
systems. 


data   used   by   other 


Certain 


types    of   applications    represent 
opportunities  for  conversion.   For  example: 


poor 


A  purchased  application  which   is   maintained   by   a 
third  party  supplier. 


An  application  which  uses  historical  data  and 
is  processed  infrequently. 


which 


A  recently  installed   application   system 
effective  in  satisfying  user  needs. 


which   is 


An  analysis  of  the  characteristics  of  the  existing 
applications  based  on  the  above  considerations  will  yield  a 
preliminary  ordering  for  conversion  of  the  application 
portfolio.  As  the  conversion  is  planned  in  more  depth  the 
preliminary  ordering  will  be  revised  and  refined  to  reflect 
such  factors  as  precedence  relationships  regardina 
conversion,  level  of  effort  required,  and  the  availability 
of  resources. 
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The  application  should  be 
trivial . 


representative   and   non- 


It  should  be  a  good   DBMS   application   (though   not 
necessarily  the  best)  . 

It  represents  a  relatively  low  risk  to  the  business. 
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It  provides  sufficient  opportunity  for  learning. 
It  is  either  an  old  system  or  technically  obsolete. 


It  provides  eventual  visibility 
management  controls. 


as   a   vehicle   for 


It  is  "owned"  by  a  vocal,  important,   but   neglected 
(by  data  processing),  segment  of  the  business. 

3.2.2  Impact  On  the  EDP  Organization.  This  section  discusses 
the  following  topics  relating  to  the  impact  of  conversion  on 
the  data  processing  organization: 

Organizational  considerations. 

Technical  aspects:  tools  and  methodologies. 

.   Data  processing  personnel  skill  requirements. 

Organizational  Considerations.  Converting  to  a  data 
base  environment  qenerally  entails  reorganization  of  the 
data  processing  function  in  order  to  provide  the  technical 
and  administrative  means  for  managing  data  as  a  resource.  A 
key  organizational  consideration  is  the  need  to  establish  a 
Data  Base  Administration  (DBA)  function  within  data 
processing.  Conversion  will  also  impact  the  applications 
development  and  computer  operations  functions  within  data 
process i  ng . 

Data  base  administration.  The  Data  Base  Administration 
TMA)"TiTnction  is  responsible  for  defining,  controlling,  and 
administering  the  data  resources  of  an  organization  The  many 
responsibilities  of  the  DBA  function  are  not  discussed  in 
detail  here  since  they  are  covered  extensively  in  the 
literature.  However,  some  of  the  major  responsibilities 
include  the  following: 

.   Data  base  definition/redefinition.    DBA  must   have 
primary   responsibility  for  defining  the  logical  and 


physical  structure  of   the 
consulting  responsibility. 


data   base,   not  merely 


Data  base  integrity.  DBA  is  responsible  for 
protecting  the  physical  existence  of  the  data  base 
and  for  preventing  unauthorized  or  accidental  access 
to  the  data  base. 

Performance  monitoring.  DBA  must  monitor  usage  of 
the  data  base  and  collect  statistics  to  determine 
the  efficiency  and  effectiveness  of  the  data  base  in 
satisfying  the  needs  of  the  user  community. 
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Conflict  mediation.  DBA  must  mediate  the 
conflicting  needs  and  preference  of  diverse  user 
groups  that  arise  because  of  data  sharing. 

Many  alternatives  exist  for  locatinq  the  DBA  function 
within  the  overall  corporate  structure.  Three  such 
alternatives  include  the  following: 


Within  the  data  processing  organization, 
to  avoid  an  application  orientation  or  a 
on  computer  efficiency,  DBA  should,  in  gen 
report  to  Applications  Development  or 
Operations,  respectively.  Rather,  DBA  sho 
to  the  highest  full-time  data  processing  e 

Corporate  level.  When  located  at  th 
corporate  level,  DBA  can  take  a  broad  vi 
as  a  corporate  resource.  Furthermore,  DBA 
position  to  resolve  conflicts  between  u 
When  DBA  resides  at  this  location,  some  of 
technical  aspects  of  the  DBA  function  are 
performed  within  the  data  processing  organ 
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.  Matrix  organization.  This  structure  is  patterned 
after  the  aerospace  industry  where  a  given  project 
draws  upon  all  functional  areas.  In  this  case,  the 
DBA  staff  would  report  functionally  to  DBA  but  would 
also  report  directly  to  a  project  manager.  This 
organizational  strategy  has  the  advantaaes  of 
recognizing  the  integration  required  for  a  data 
base,  puts  DBA  at  an  equal  level  with  other 
functional  areas,  and  serves  to  increase 
communication  during  application  development. 

Within  the  DBA  function,  the  two  basic  organizational 
strategies  are  functional  specialization  versus  application 
area  specialization. 


Functional  Specialization.  This  strategy  organizes 
DBA  according  to  functions  performed,  such  as  data 
base  design,  performance  monitoring,  data 
dictionary,  and  so  on.  This  approach  has  the 
disadvantage  of  ensuring  that  no  one  person  is 
knowledgeable  about  all  aspects  of  DBA  support  for  a 
particular  application  system. 

Application  Area  Specialization.  In  this  approach, 
one  person  within  DBA  is  responsible  for  performing 
all  DBA  functions  for  a  particular  application  area, 
including  both  application  development  and 
operation.  This  approach  has  the  disadvantage  of 
developing   expertise  within  functional  areas  of  DBA 
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more  slowly.  Furthermore,  unless  controlled, 
activities  within  DBA  may  become  fragmented. 
However,  this  approach  results  in  an  interesting  and 
challenging  job  and  facilitates  attracting  and 
keeping  capable  personnel. 


Appl i cations   devel opment.    Conversion   to   a 
environment   wTTT    aTTect    the   applications 
function  within  the  data  processing  organization 
ways.     The   most   fundamental   impact   upon 
devel opment 
orientation   to   a 


data  base 
devel opment 
in  several 
appl i cations 
will  be  the  change  from  an  applications 
to  a  data  orientation.  Conversion  to  a  data 
base  environment  should  also  broaden  the  scope  of  the 
application  developers.  Specifically,  the  developers  need 
to  understand  the  basic  business  processes  and  to  develop 
application  systems  that  cross  organizational  boundaries. 

The  application  development  methodology  will  have  to  be 
modified  by  delimiting  the  relative  responsibilities  of  both 
DBA  and  applications  development.  Moreover,  the  basic 
approach  to  application  development  may  be  revolutionized  as 
a  result  of  conversion  to  a  DBMS.  Specifically,  instead  of 
a  rigorous  approach  to  application  development,  the  DBMS  may 
permit  an  iterative  or  convergence  approach.  With  this 
approach,  user  requirements  are  not  defined  in  detail  before 
developing  the  application  system.  Rather,  user 
requirements  are  defined  at  a  more  general  level  and  a 
system  is  quickly  built  using  the  DBMS.  When  presented  with 
the  system  outputs,  the  user  specifies  any  required  changes, 
which  are  then  incorporated  into  the  system.  This  process 
is  repeated  until  the  application  system  satisfies  user 
needs.  Note  that  this  approach  to  application  development 
requires  a  DBMS  in  which  data  base  definition,  creation,  and 
redefinition  and  report  writing  are  quickly  and  easily 
accompl i  shed . 

Computer  operations.  Conversion  to  a  data  base  environment 
wTTI  Trnplct  tfie  Computer  Operations  function  in  two  ways. 
First,  many  of  the  responsibilities  of  computer  operations 
function  will  be  transferred  to  the  newly  established  DBA 
function.  Second,  the  characteristics  of  the  application 
systems  may  change.  Specifically,  the  DBMS  may  facilitate 
the  development  and  operation  of  on-line  applications  as 
opposed  to  the  more  traditional  batch  systems. 
Consequently,  the  computer  operations  function  may  have  to 
reorganize  to  operate  within  this  more  dynamic  environment. 

Technical  Aspects  --  Tools  and  Methodologies.  Because 
the  subject  of  DBMS  selection  has  been  covered  adequately  in 
the  literature,  it  was  not  addressed  by  this  panel. 
However,  the  following  are  some  of  the  tools  and 
methodologies  typically  required  in  making  effective  use   of 
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the  DBMS  after  its  installation: 

Data  dictionary/directory.  A  tool  for  organizing, 
documenting,  inventorying,  and  controlling  data.  It 
provides  for  a  more  comprehensive  definition  of  data 
than  is  possible  in  the  DDL  facility  of  most 
commercial  DBMS's.  As  such,  it  is  essential  for 
management  of  data  as  a  resource. 

Data  base  design  and  validation  tools.  Used  to 
facilitate  the  design  process  and  to  validate  the 
resultant  design  prior  to  programming.  Included  in 
this  category  are  such  tools  as  hashing  algorithm 
analyzers  and  data  base  simulation  techniques. 


Performance  monitoring  tools.  Useful  in  analyzing 
and  tuning  the  physical  data  base  structure.  These 
tools  provide  statistics  on  data  base  usage  and 
operation. 


Application  development  tools.  Used  to  facilitate 
the  development  of  application  systems,  including 
such  tools  as  terminal  simulators  which  operate  in 
batch  mode  and  test  data  base  generators. 

Data  base  storage  structure  validation  utilities. 
Used  to  verify  that  a  stored  data  base  conforms  to 
its  definition  or  to  assess  the  extent  of  damage  of 
a  damaged  data  base.  Examples  include  a  "chain 
walker"  utility. 

Query/report   writer   facility.  Enables   users   to 

access  the  data  base  and  extract  data  without  having 

to  write  a  procedural  program  in  a  conventional 
programming  language. 

Data  base  design  methodology.  Needed  to  standardize 
tbe  approach  to  data  base  design  and  to  provide 
guidance  in  using  the  data  base  design,  modeling, 
and  monitoring  tools. 

Application  development  methodology.  Specifies  the 
standardized  approach  to  developing  application 
systems;  i.e.,  the  activities  to  be  performed  during 
the  development  process  and  the  corresponding  roles 
and  responsibilities  of  each  of  the  various  project 
participants.  Of  particular  importance  is  the  need 
to  define  the  points  in  the  development  process  at 
which  DBA  and  applications  development  functions 
must  interface  and  the  relative  responsibilities  of 
each  with  respect  to  application  development. 
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Documentation  methodologies.  Needed  by  DBA  to 
document  data  definitions  uniformly  and  to  document 
data  base  design  decisions. 


Data  Processing  Personnel  Skill 
impact  of  conversion  to  a  data  base 
requirements  will  be  considered  in  this 


Requi  rements .  The 
environment  on  skill 
section. 


Types  of  skills.   The  following  types  of  skills 
in  a  data  base  environment: 


are   needed 


.  Data  Base  Administration.  DBA  should  be  staffed 
with  individuals  who  are  strong  technically, 
interface  well  with  people,  and  collectively  are 
knowledgeable  about  the  DBMS  itself,  the  tools 
necessary  to  support  it,  the  application  development 
process,  and  the  corporation  and  its  data. 

.  Logical  data  base  design.  Within  DBA  there  is  a 
need  for  individuals  possessing  the  ability  to 
recognize  and  catalog  data  elements,  to  group 
related  data  elements,  identify  relationships 
between  groups,  and  to  use  the  data  description 
1 anguage . 

.  Physical  data  base  design.  Within  DBA  there  is  a 
need  for  individuals  knowledgeable  with  respect  to 
organization  techniques,  data  compression,  trade- 
offs in  data  base  design,  simulation,  and  modeling 
techn  i  ques  . 

DML  programming.  DBA  should  include  individuals 
with  knowledge  of  the  DML  and  its  associated  host 
language,  data  base  navigation,  and  the  currency 
concept . 

Acquisition  and  training.  Obviously,  the  required  skills 
may  be  developed  internally  or  acquired  externally.  Hiring 
the  required  personnel  has  the  advantage  of  bringing 
experience  and  new  ideas  into  the  data  processing 
organization.  However,  individuals  knowledgeable  with 
respect  to  DBMS  are  scarce  and  hence  expensive.  Moreover, 
individuals  brought  in  from  the  outside  typically  have 
little,  if  any,  knowledge  of  the  business. 

Developing  skills  internally  has  the  advantage  of 
building  DBMS  skills  on  top  of  knowledge  of  the  business. 
Furthermore,  control  can  be  exercised  over  what  is  learned 
and  when.  Finally,  it  is  generally  less  expensive  and 
disruptive  than  hiring. 
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When  skills  are  developed  internally,  there  are  several 
possible  approaches  to  training: 


In-house.    In   this   approach,    sta 
possessing   the   necessary  skills  teac 
to  others  by  means  of   courses   or   jo 
This   approach  may  fit  well  with  initi 
development  and  has  no   cash   cost, 
mere   act  of  having  to  teach  their  sk 
enhances  the   knowledge   and   understa 
teachers     themselves.     There 
disadvantages  to  this   approach:    it 
time   of  the  most  capable  personnel  wh 
more  effectively  used  elsewhere;  it  ca 
where   the   required  skills  do  not  exi 
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Vendor.  This  approach  utilizes  the  courses  offered 
by  DBMS  and  support  software  vendors.  Vendor 
courses  may  be  a  relatively  inexpensive  approach 
particularly  when  courses  are  bundled  as  part  of  the 
purchase/lease  price.  Furthermore,  the  internal 
staff  are  likely  to  benefit  from  the 
the  vendor.  However,  the  courses 
thinly-disguised  sales  pitch. 


may 


expertise 
be   only 


of 
a 


Other  approaches, 
include: 


Additional  approaches  to  training 


-independent  educational  organizations 
-colleges  or  universities 
-videotape/cassette  courses 


may   resul t 


Turnover.  Conversion  to  a  data  base  environment  ,„UJ  ,,,,,, 
in  employee  turnover.  The  new  DBMS  may  be  perceived  by  the 
staff  as  being  threatening  and,  hence,  may  be  resisted. 
This   resistance   to  change  may   be  overcome   somewhat  by 


involving  the  staff  in  the  series  of  decisions  leading  to 
the  acquisition  of  a  DBMS.  If  required  skills  are  obtained 
through  hiring,  the  existing  employees  are  likely  to   resent 

Finally,  as 
,      .  -   -   -    - ■ r   market  val ue 

and  it  becomes  increasingly  expensive  to  retain  the  staff, 
mese  three  factors  --  resistance  to  change,  resentment  of 
new  hires,  a.nd  increased  employee  market  value  --  tend  to 
increase  turnover  following  conversion  to  a  DBMS 
environment. 


wniwuyn  luring,  trie  e  x  i  s  i  i  n  g  employees  are  like 
the  high  salaries  paid  to  the  new  employees, 
the  skills  of  the  staff  increase,  so  does  their 
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On  the  other  hand,  certain  factors  tend  to  decrease 
turnover.  Specifically,  conversion  to  a  data  base 
environment  involves  new  opportunities  for  individual  growth 
and  excitement  such  as  new  technology,  new  hardware  and 
software,  and  major  development  efforts.  Properly 
exploited,  these  factors  can  increase  job 
correspondingly  decrease  turnover. 


satisfaction  and 


the 
data 


3.2.3  Impact  On  Planning  and  Control  Systems.  With 
exception  of  the  chargeout  mechanism,  conversion  to  a 
base  environment  will  not  affect  the  basic  mechanisms  for 
planning  and  control.  However,  recognize  that  conversion  is 
itself  a  process  to  b£  managed.  This  entail s  applying 
justification  procedures  for  conversion,  planning 
conversion,  establishing  review  and  approval 
and  monitoring  progress. 


the 
check  points, 


Planning  the  Conversion, 
requires    the    involvement 
processing  management: 


Planning  for   the   conversion 
of   senior,   user,   and   data 


Attempts  to  convert  to  a  data  base  environment 
without  senior  management  support  runs  a  high  risk 
of  failure.  If  senior  management  has  not  formally 
authorized  DBMS  studies  or  incorporated  DBMS 
planning  into  corporate  plans,  the  probability  of 
successful  conversion  is  remote. 

Conversion  will  have  a  significant  impact  on  user 
departments  in  the  form  of  disruption  of  normal  data 
processing  services,  restructuring  «of  application 
systems,  and  a  change  in  orientation  on  the  part  of 
users  from  ownership  to  sharing  of  data. 
Consequently,  user  involvement  in  planning  the 
conversion  is  critical. 

Conversion  to  a  DBMS  generally  affects  the 
structure,  system  development  methodology,  personnel 
skill     requirements,     and     hardware/software 


configuration   of  the 
lead   time   necessary 
infrastructure    for 
environment  must   be 
accordingly . 


data  processing  function.  The 
to  develop  the  appropriate 
operating    in   a   data   base 

appreciated   and   planned   for 


Given  senior  management  support  for  the  conversion,  one 
strategy  for  obtaining  the  required  involvement  in  the 
planning  process  is  to  establish  a  steering  committee  for 
the  data  base  as  mentioned  in  the  earlier  section  on 
Maintenance  Moratorium.  This  steering  committee  contains 
representatives  from  both  user  departments  and  from  data 
processing  and  is  responsible  for  controlling  the   evolution 
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the  Data  base  Steering  Committee 


of  the  data  base.   As  such, 

is  subordinate  to  the  data  processing  Strategic  Steering 
Committee,  which  is  concerned  with  the  evolution  of  the 
entire  data  processing  function  within  the  enterprise. 


of  the   target   data 
represents   a   model 


Given  the  appropriate  participation,  a  necessary  first 
step  in  converting  from  a  non-data  base  to  a  data  base 
environment  is  the  development  of  an  architectural  plan  for 
the  data   base.   This  plan  describes  the  intended  structure 

base.  Conceptually,  a  data  base 
or  image  of  the  organization  which  it 
serves.  In  order  for  the  data  base  to  represent  an  accurate 
image  of  the  organization,  it  is  necessary  for  the  data  base 
structure  to  reflect  the  fundamental  business  processes 
performed  in  the  organization.  Consequently,  the  designers 
of  the  data  base  must  first  understand  the  key  decisions  and 
activities  required  to  manage  and  administer  the  resources 
and  operations  of  the  enterprise.  This  typically  entails  a 
cross-functional  study  of  the  enterprise  in  order  to 
identify  the  business  processes  and  information  needs  of  the 
various  user  departments. 

The  architectural  plan  permits  planning  and  scheduling 
the  migration  of  application  programs,  manual  procedures, 
and  people  to  a  data  base  environment.  This  implementation 
plan  must  incorporate  review  and  approval  checkpoints  that 
enable  management  to  control  and  monitor  the  conversion 
process  . 

Controlling  the  Conversion.  The  actual  conversion  to  a 
data  base  environment  is  effected  by  a  project  team  composed 
of  representatives  from  user  departments,  applications 
development,  and  data  base  administration.  At  formally 
established  checkpoints  during  the  conversion,  the  data  base 
steering  committee  reviews  the  progress  of  the  project. 
Items  reviewed  and  analyzed  include  the  following: 

.   Projected  benefits  vs.  actual  benefits 


Data  qual i  ty  (i.e., 
availability) 


completeness,   timeliness,   and 


Projected  operating  and  development  costs  vs.  actual 
costs 

Actual  costs  of  collecting,  maintaining,  and  storing 
data  vs.  benefits  realized 
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Project  performance  (i.e.,  performance  of  the 
project  team  against  the  conversion  schedule  and 
budget) 

Based  on  the  review,  the  data  base  steering  committee 
takes  the  appropriate  approval  action  (e.g.,  go/no  go)  with 
respect  to  the  conversion  activity. 

Chargeback  Considerations.  The  costs  of  operating  in  a 
data  base  (i.e~  shared  data)  environment  are  extremely 
difficult  to  charge  back  to  individual  users  in  an  equitable 
manner.  At  best,  complex  job  accounting  systems  can  only 
approximate  actual  resource  usage.  Moreover,  the  chargeback 
algorithm  must  not  be  dysfunctional  with  respect  to  its 
impact  on  the  various  user  departments.  Conversion 
data  base  environment  frequently  requires  that  a 
department  supply  data  which  it  does  not  itself  use. 
chargeback  algorithm  must  reward,  not  penalize, 
behavior  on  the  part  of  the  user  department. 


to   a 

user 

The 

such 


an    appropriate 


Some   considerations   in   developing 
chargeback  algorithm  include  the  following: 

.  Consider  capitalization  of  the  costs  of  conversion 
instead  of  treating  such  costs  as  current  expense  in 
order  to  avoid  inhibiting  user  departments  from 
undergoing  the  conversion. 

.  User  departments  typically  have  little  control  over 
the  costs  of  conversion.  Consequently,  consider 
treating  such  costs  as  unallocated  overhead,  since 
allocation  will  have  little  effect  on  the  decisions 
or  efficiency  of  the  user  departments. 

.  Because  ongoing  costs  of  collecting,  maintaining, 
and  storing  data  are  difficult  to  associate  with 
individual  users,  consider  developing  percentage 
allocation  factors  for  these  costs  based  on  periodic 
reviews  of  data  base  usage.  Alternatively,  consider 
treating  these  costs  as  overhead. 

Resource  usage  for  retrieval  and  processing  purposes 
are  easier  to  approximate,  and  such  costs  should  be 
charged  directly  to  the  users. 

Consider  incorporating  a  reverse  charging  mechanism 
into  the  chargeback  algorithm  in  order  to  compensate 
users  who  supply  data  which  they  do  not  use. 


3.2.4  Impact  of  Conversion  On  User  Awareness.  The  most 
fundamental  impact  of  conversion  to  a  data  base  environment 
is  the  required  change  in  orientation  on  the  part  of  users. 
No  longer  are  files  and  applications  "owned"  by  a  particular 
user  department.  Rather,  data  must  be  viewed  as  a  corporate 
resource  to  be  shared  by  all  user  departments.  The 
requirement  for  sharing  constrains  the  freedom  of  a  user  to 
change  arbitrarily  and  unilaterally  the  definition  of  the 
data . 

Sharing  of  data  will  impact  users  in  a  second  way. 
Following  conversion  to  a  data  base  environment,  users  may 
be  required  to  supply  data  which  they  themselves  do  not  use. 
As  already  discussed,  the  chargeback  algorithm  must  be 
structured  to  reward  such  behavior.  Furthermore,  suppliers 
of  data  in  general  must  be  infused  with  a  sense  of 
responsibility  (not  ownership)  for  the  data  in  order  to 
maintain  data  quality. 


Conversion  to  a  data  base  environment 
user  community  in  other  ways: 


may   impact   the 


Planning  the  conversion.  User  participation  in 
developing  both  the  architectural  plan  and 
implementation  plan  is  necessary  in  order  to  obtain 
user  commitment  and  to  ensure  that  the  resultant 
data  base  satisfies  user  needs. 

Disruption  of  operations.  Normal  data  processing 
services  are  likely  to  be  severely  disrupted  as  a 
result  of  such  factors  as  limited  availability  of 
personnel  and  maintenance  moratoriums.  Furthermore, 
the  conversion  may  disrupt  and  strain  user 
operations  as  new  and  old  applications  are  operated 
i  n  p  a  r  a  1 1  e  1  . 

Resolution  of  inconsistencies.  Creation  of  the  data 
base  typically  entails  merging  of  application- 
oriented  files.  During  this  process, 
inconsistencies  in  both  data  definitions  and  data 
values  are  identified.  These  inconsistencies  must 
then  be  resolved  by  the  relevant  user  departments. 

Structure  of  user  department.  The  structure  of  a 
user  department  may  no  longer  be  effective  following 
conversion;  e.g.,  the  user  department  may  be 
designed  around  a  particular  application  system. 
Restructuring  application  systems  during  conversion 
may  precipitate  user  reorganization. 
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New  organizational  roles.  Conversion  may  cause  new 
organizational  roles  to  evolve  in  user  departments. 
For  example,  in  order  to  provide  coordination 
between  Data  Base  Administration  and  the  user 
departments,  a  "user  data  administrator"  may  evolve. 
The  user  data  administrator  serves  as  the  focal 
point  for  participation  and  involvement  on  the  part 
of  the  user  department  both  during  and  subsequent  to 
the  conversion. 

Systems  analysis.  By  providing  such  tools  as  a 
high-level  query  language  and/or  a  generalized 
report  writer,  the  DBMS  enables  non-technical  users 
to  access  the  data  base  directly;  i.e.,  users  are 
less  dependent  upon  programmers  to  satisfy  simple 
requests  for  information, 
availability  of  data  may  result 
the  systems  analysis  function 
to  user  departments. 


This  increased 
in  the  migration  of 
from  data  processing 


Personnel  skill  requirements.  Conversion  may  impact 
the  skill  requirements  of  user  personnel.  For 
example,  conversion  to  a  data  base  environment  may 
also  result  in  operating  certain  application  systems 
online,  requiring  that  the  user  department  acquire 
or  develop  terminal  operations  skills. 


3.3   MINIMIZING  THE  IMPACT  OF  FUTURE  CONVERSIONS 

The  initial  conversion  to  a  data  base  environment  is 
not  likely  to  be  the  only  data  base-related  conversion  that 
an  enterprise  will  undergo.  Rather,  conversions  of  one  form 
or  another  are  likely  to  be  a  way  of  life.  However,  there 
are  certain  measures  that  the  data  processing  organization 
can  take  to  minimize  the  impact  of  future  conversions, 
including: 

Institutionalization  of  the  Data  Base  Administration 
function. 

Insulation  of  programs  from  a  particular  DBMS. 

DBMS  independent  data  base  design. 

3.3.1  Institutionalization  of  the  DBA  Function.   A    well- 
DBA  function  will  minimize  the  impact  of  future 
conversions.    Specifically,   the   DBA   function 


establ ished 
data   base 
shoul d  take 


action  as  follows 
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Maintain   data    definitions    and 
up-to-date    data    dictionary. 


relationships   in 


an 


Document  -the  structure  and  contents  of  all  data 
bases  independently  of  the  data  description  language 
of  the  DBMS. 

Develop  methodologies  and  standards  for  data  base 
design  which  are  independent  of  any  particular  DBMS. 


3.3.2  DBMS  Independent  Data  Base  Desian.  The 
the  ANSI/X3/S 
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3.3.3  Insulate  Programs  From  the  DBMS.  Two  sets  of 
circumstances  may  motivate  a~n  organization  to  attempt  to 
insulate  its  application  programs  from  any  one  DBMS.  On  the 
one  hand,  an  organization  may  be  unwilling  to  commit 
completely  to  the  use  of  a  particular  DBMS.  Rather,  it  may 
desire  to  keep  its  options  open  with  respect  to  converting 
to  a  different  DBMS  at  a  later  date.  Alternatively,  a  large 
multi-division  corporation  may  desire  to  develop  common 
application  systems  for  the  divisions;  yet  it  may  find  that 
the  data  processing  organizations  within  autonomous 
divisions  have  installed  different  DBMS's. 

It  is  possible  to  build  an  interface  between 
application  programs  and  the  DBMS  in  order  to  isolate  the 
programs  from  the  DBMS.  That  is,  the  programs  do  not 
interact  directly  with  the  DBMS.  Rather,  standard  program 
requests  for  DBMS  services  are  translated  into  the  required 
DML  statements  either  at  compilation  time  or  at  execution 
time.  Thus,  application  programs  are  insulated  from  changes 
in  the  DBMS  as  long  as  an  interface  module  can  be  developed 
to  translate  program  requests  into  the  DML  statements  of  the 
new  DBMS.  Similarly,  a  single  application  will  execute 
under  any  number  of  DBMS's  as  long  as  the  appropriate 
interface  modules  exist.  Furthermore,  the  multi-division 
corporation  retains  the  flexibility  of   standardizing   on   a 
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single  DBMS  at  a  future  date.  The  negative  aspects  of  this 
approach  include  reduced  system  efficiency  and  the 
possibility  of  ending  up  with  a  pseudo-DBMS  whose 
capabilities  represent  the  lowest  common  denominator  of  the 
various  DBMS's  for  which  interfaces  are  built  or  planned. 
Nevertheless,  a  number  of  corporations  worldwide  have 
adopted  or  are  adopting  this  approach. 

3.4   CONVERSION  FROM  ONE  DBMS  TO  ANOTHER  DBMS 

As  a  data  processing  organization  goes  through  the 
experiential  learning  necessary  to  assimilate  data  base 
technology,  the  functions  and  features  of  the  data  base 
management  system  package  currently  installed  will  tend  to 
be  more  highly  utilized.  Users  will  have  positive 
experiences  with  the  facilities  offered  by  the  DBMS  and  will 
subsequently  place  greater  burdens  on  those  facilities. 
Also,  the  technical  capabilities  of  the  DBMS  will  be 
increasingly  utilized  by  the  data  processing  staff  in  order 
to  meet  user  requirements. 

In  short,  the  tendency  to  use  the  full  functions  of  the 
DBMS  over  time  will  place  a  strain  on  the  capabilities  of 
the  DBMS.  This  is  manifested  by  either  decreasing  systems 
processing  efficiency  or  increasing  effort  necessary  to 
develop  systems  which  meet  user  needs.  These  increased 
costs  are  recognized  by  both  users  and  data  processing 
personnel  who  then  initiate  a  search  for  increased  DBMS 
capabilities  and,  thus,  begin  data  base  conversion  effort. 

This  second  type  of  data  base  conversion  can  be 
characterized  by  either  a  complete  change  in  data  base 
management  system  packages  or  an  upgrade  in  the  version  of 
the  DBMS  currently  installed.  This  section  discusses  the 
impact  of  the  conversion  from  one  data  base  system 
environment  to  another  on  each  of  the  four  growth  processes 
previously  discussed.   The  section  is  organized  as  follows: 

Reasons  to  go  through  the  conversion. 

Economic  considerations  of  the  conversion  effort. 

Conversion  activities-  and  their  impacts. 

Developing  a  strategy  for  the  conversion. 
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3.4.1  R e a s o ns  for  Conversion, 
discussed, 


"tTTe" 


_   _   As    has    been    previously 

most   prevalent   reason   to   undertake   a 


conversion  from  one  DBMS  to  another  DBMS-1  to  DBMS-2 
Conversion  is  to  install  a  better  DBMS.  A  better  DBMS  is 
usually  defined  as  having: 

Improved  functions  (more  complete). 

Better  performance. 

Improved  query  capability. 

Development  of  richer  data  structures. 

More   efficient   usage   of   the   computer   resource 
through  decreased  cycles  and/or  space. 

Improved  or  added  communication  functions. 

Availability  of  transaction  processing. 

Distributed  processing  capability. 

Another  major  reason  to  undertake  a  DBMS-1  to  DBMS-2 
Conversion  is  to  standardize  DBMS  usage  within  the  company. 
Many  large  corporations  are  finding  that  the  DBMS  selections 
made  several  years  ago  to  meet  specific  application  needs 
have  resulted  in  the  installation  of  several  DBMS  packages 
within  the  data  processing  organization.  The  impact  of 
multi-DBMS  usage  in  a  single  data  processing  environment  is 
major .   For  exampl e: 

Application  programs  are  constrained  to  the  design 
and  processing  characteristics  unique  to  each  DBMS. 

Data  files  are  structured  to  be  accessed  by  a  single 

DBMS. 

Design  and  programming  personnel  develop  the  skills 
necessary  to  implement  systems  associated  with  a 
single  DBMS. 

The  multi-DBMS  environment  results  in  a  substantial 
investment  in  data  processing  personnel  technical  skills  and 
reduces  the  potential  for  integrating  applications  that 
operate  on  different  DBMS's. 

For  these  reasons  many  companies  are  now  developing 
standards  for  data  base  management  system  usage.  Those 
standards  are  usually  application  systems  to  be  developed 
under  a  single  DBMS.  Exceptions  may  exist  where  the 
application  to  be  developed  is  stand-alone  in  nature  with   a 
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low  potential  for  integration  with  other  systems. 

The  last  major  reason  for  DBMS-1  to  DBMS-2  conversion 
is  that  such  a  conversion  is  dictated  by  a  hardware  change. 
Many  of  the  commercially  available  DBMS's  Tre  ofTeTed  b"y 
large  mainframe  vendors.  As  such,  a  move  from  one  hardware 
vendor  to  another  will  necessitate  a  change  in  DBMS  usage. 
This  can  become  quite  a  complex  effort  in  that  the  source 
code  and  data  base  storage  structures  of  all  programs  will 
require  changes.  If  there  is  a  history  of  hardware 
conversions  in  the  company,  the  wise  data  processing  manager 
should  select  a  DBMS  that  is  not  hardware  dependent. 


3.4.2  Economic  Considerations.   A 
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The  economic  justification  for  a  DBMS-1  to  DBMS-2 
conversion  should  be  based  on  a  succinct,  articulation  of  the 
COSTS  and  BENEFITS  di  rectly  associated  with  the  conversion 
effort.  Costs  should  be  identified  on  an  incremental  basis 
and  be  classified  into  three  categories: 

One-time  conversion  costs. 

Incremental  costs  for  each  planned  application  to  be 
converted  to  the 


new  DBMS. 

On-going  DBMS  support  costs. 

Benefits  should  likewise  be  identified  on  an 
incremental  basis  within  the  same  time  frames  as  the 
associated  costs.   Benefits  are    divided  into  two  categories: 


Discernible/definable  cost  savings 
maintenance,  and  operations. 


in   devel opment , 
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Intangible  cost  savings. 

A  more  complete  description  of  the  types  of  economic 
considerations  to  be  addressed  is  contained  in  DATA  BASE 
DIRECTIONS:  THE  NEXT  STEPS,  National  Bureau  of  StTFdlFdT 
Special  Tub  1  i  ca  t i  on  45 1 . 

Above  ill,  the  justification  for  _a  data  base  conversion 
shoul  d  be  devel  oped  and  communicated  to  management  in  the" 
same  manner  that  any~other  project  is  justified. 

3.4.3  Conversion  Ac tivi ties  and  Their  Impact.  The  impact  of 
a  DBMS-1  to  DBMS-2  conversion  effort  can  be  felt  on  each  of 
the  four  growth  processes  previously  discussed.  Many  of  the 
types  of  impacts  are  the  same  as  those  previously  identified 
in  a  conversion  t£  data  base   technology.    Users   and   data 


exDeriln^^r^rnr*  Sh0Uld  reco9n^that  many  of  the  same 
experiential  learning  processes  occur  in  subsequent  data  base 
conversions  as  they  do  in  the  initial  effort. 


Impact  On   Application   Portfol io .    The    impact   of 
subsequent   data   base  conversions  on  application  portfolios 

occurs  in  three  areas: 

Application  programs. 
Data  bases . 


Ca  tal ogued  modul es . 

Application  programs .  Because  application  programs  are 
buffered  from  actual  data  storage  structures  by  the  DBMS, 
the  unique  characteristics  of  each  DBMS  will  have  a  major 
impact  on  application  programs  in  the  following  areas: 


and   mappings    (model, 


.   DBMS  "call"  structures. 

Programs   view  of   data 
structure  ,  content) . 

Application  program  logic. 

Data  communications. 

Data  bases .  Physical  data  storage  structures  and  logical 
data  relationships  are  implemented  via  unioue  DBMS  utilities 
and  are  patterned  after  distinct  DBMS  requirements.  As 
such,  data  bases  developed  under  one  DBMS  are  not  readily 
accessible  by  other  DBMS  packages.  Specifically,  data  bases 
are  impacted  by  the  vagaries  of  data  base  management  systems 
in  the  following  ways: 
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.   Data  base  definitions  in  both  the  DBMS   and   in   the 
Data  Dictionary. 

Data  content  and  storage  format. 

Use  of  data  base  design  and  simulation  aids. 

Conversion  aids. 

Catalogued  modul es.  Though  processed  just  as  any  other 
program,  catalogued  modules  differ  from  application  programs 
in  their  function  and  method  of  development.  The  specific 
types  of  catalogued  modules  which  are  impacted  by  a  change 
in  DBMS  are: 

Catalogued  queries. 

Catalogued  report  definitions. 


Catalogued  transaction  definitions. 
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The  major  organizational  impact  throughout  both  data 
processing  and  users  areas  is  likely  to  be  in  the  technical 
and  functional  education  required  before,  during,  a"nd  after 
tKe  conversion  effort.  Data  processing  and  user  personnel 
in  all  areas  of  systems  development  and  operation  will  have 
to  be  trained  on  the  new  aspects  of  the  DBMS.  Training 
programs  for  all  people  should  be  identified  and  initiated 
in  advance  of  the  conversion  implementation. 

Another  major  area  of  impact  on  the  data  processing 
organization  from  a  data  base  conversion  is  the 
modifications  in  documentation  necessary  to  accommodate  the 
new  DBMS  environment.  Changes  in  documentation  will  occur 
in  the  following  areas: 
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DBMS  functional  and   technical   support   (reference) 
documentation . 

Functional   and   technical   descriptions   of   any 
application  systems  converted  onto  the  new  DBMS. 

Physical  and  logical  descriptions  of  any  data   bases 
converted. 

.  User-oriented  descriptions  of  application  systems 
processing  characteristics. 

.  System  development  methodology  documentation  that 
references  particular  aspects  of  data  base  or 
application  development. 

Impact  On  Data  Processing  Management  Control  Systems. 
As  previously  discussed,  Data  Processing  Management  Control 
Systems  comprise  those  sets  of  procedures  regularly  used  to 
control  both  systems  development,  and  operations  functions. 
The  conversion  from  one  DBMS  to  'another  is  not  going  to 
modify  the  conceptual  framework  used  to  control  the  data 
processing  environment.  However,  specific  changes  will 
affect  the  mechanics  of  control : 

Data  processing  budgeting  and  user  chargeback .  The 
chargeback  algorithm  used  to  charge  users  for  data 
processing  services  is  likely  to  change  because  of 
modifications  in: 

DBMS  overhead  (cycles). 

DBMS  space  requirements. 

methods  of  implementing  logical  relationships. 

ownership  of  data  items. 

differences   in   efforts   required   to   design   and 
implement  application  systems. 

differences  in   methods   used   to   structure   ad-hoc 
queries  and  periodic  reports. 

methods  of  charging  end-user  cost  centers   for   the 

one-time   costs   of   conversion.  The  time-frame  of 

allocating  these  charges  can  also  be  important   (one 
lump  sum  vs.  periodic  payments). 

Systems  devel opment  methodology. 
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There  will  be  changes  in  the  time  frame  and  types  of 
effort  required  in  systems  development. 

Conceptual  approach  to  developing  systems  may  change 
due  to  total  effort  or  time  frame  required  to 
generate  sample  reports  on  test  data  bases. 

Design  procedures  in  the  methodology  not  likely  to 
change  if  DBMS  facilities  are  similar;  only  jargon 
should  change  in  documentation. 


standards  by 
are  regul arly 
functions   and 


monitors    and 
new   processing 


Data  processi  ng  performance  measurement. 

Systems   development   and   operations 
which    data    processing   personnel 
measured  should  change   due   to   new 
especially  to  a  new  learning  curve. 

Computer  operations  performance 
standards  will  change  due  to 
technol ogy . 

In tegri  ty  control  . 

Adequate   data   base   backup   should   be   carefully 
analyzed  and  managed  during  the  conversion  process. 

Operational  restart/recovery  procedures  will  change 
due  to  new  DBMS  functions  or  utilities. 

Processing  of  data  exceptions  may  differ. 

Securi  ty  control . 

Differences  in  methods  of  data  access  security 
should  be  recognized. 

Data  manipulation  restrictions  may  vary  from  DBMS-1 
to  DBMS-2. 

Pr i  vacy  control . 

Where  appropriate,  special  care  should  be  taken  that 
all  privacy  disclosures  are  logged  during  a  data 
base  conversion  per  recent  government  regulations. 

Impact  On  User  Areas .  A  key  note  of  data  base 
conversions  Ts  that  the  conversion  shoul d  be  as  transparent 
as  possible  to  user  areas .  This  axiom  holds  that  the 
processing  Tmpac t  on  user  areas  should  be  held  to  a  minimum 
and  that  the*  necessary  technical  capabilities  to  support  the 
conversion  should  reside  in  the  data  processing  area. 
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The  impact  of  the  data  base  conversion  effort  should  be 
readily  apparent  to  users  regarding: 

Functional  improvements  (e.g.,  new  query  language). 

Increased   data   content   (e.g.,   "while   we    are 
changing,  let's  add  ..."). 

Increase  in  sharing   of  data  will   highlight  data 
inconsistencies,  validations,  and  format  errors. 

Possible   planned   disruption   of   services   during 
conversion  period. 

Data  ownership  changes. 

User  mental  images  or  expectations  may  change. 

Archival  data  capabilities  may  change  (e.g.,  meeting 
the  needs  of  IRS,  EEO,  etc.). 

3.4.4  Developing  a  Conversion  Strategy.  The  well-managed 
data  processing  installation  should  carefully  articulate  a 
data  base  conversion  strategy  and  plan  before  initiating  any 
conversion  effort.  Specifically,  the  <Jata  processing 
management  personnel  should  do  the  following: 

Determine  specific  conversion  objectives. 

Analyze   pros   and   cons   and   develop   a   memo   of 
rationale. 

Develop  a  conversion  strategy. 

Develop  a  detailed  plan  for   procedures,   data,   and 
programs . 

The  following  is  a  list  of  possible   strategies  which 
may  be  undertaken: 


Unbundle  conversion   of   procedures,   programs,   and 
data  (conversion  may  affect  all) 

Build   bridge   from   old   programs   to    new   data 
structures 

Convert  non-vital  program  first 

Migrate  data  and  program  conversion   as   maintenance 
threshold  is  approached 
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Consider  bringing  in  outsiders  to  convert  procedures 
Run  parallel  for  vital  systems: 

-frustrated  users  may  be  a  problem. 

-you  will  probably  be  turning  up  old  bugs. 

-parallel  may  be  security  blanket  only. 

Avoid  parallel  running  where  possible  by  careful 
planning  and  phased  cut over  or  "fast"  cutover  with 
fall  back  contingency  plan,  but  note  the  possibility 
of  high  risk  exposure. 

Map  how  all  users  use  the  shared  resources. 

Split  input  stream  between  old  and  new  applications 
and  plan  valildity  checks  carefully. 

Use  DBMS  facilities  such  as  dumping/loading  and 
mapping,  if  available. 

Convert  data  all  at  once,  then  convert  programs  as 
needed . 

Restructure  data  if  necessary  before  any  program 
conversion. 

Benchmark  first. 

Once  the  appropriate  conversion  strategy  is  determined, 
a  detailed  conversion  plan  should  be  developed.  The 
following  is  a  list  of  considerations  to  reference  when 
developing  a  conversion  plan: 

Develop   a   work   plan   as   in   any   other   systems 
development  effort. 

Append  original  feasibility  documents  and  review  in 
the  light  of  latest  detailed  specifications  for 
conversion. 

Re-evaluate  "Go/No  Go"  at  pre-defined  checkpoints  in 
conversion  process. 

Subject  the  conversion  process  to  standard  project 
management  control . 
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Develop  a  contingency  plan. 

Use  planning  document  as  an  education  tool  for 
project  personnel. 

Evaluate  and  select  conversion  aids. 

Flesh   out   impacts   (see   section  on   Conversion 

Activi  ties   and   their  Impact  above)  into  manageabl e 

tasks .  Schedule  these  tasks  and  establish  a 
reasonable  work  breakdown  structure. 

Go  through  planning  document  with  an  implementation 
hat  on . 

Control  project  on  at  least  a  weekly  basis. 

Plan  for  heavy  user  involvement  in  data  translation 
to  resolve  inconsistencies  and  consolidate 
validation  checks. 

Involve  external  and  internal  audit  staffs. 


3.5   SUMMARY 

In  summary,  the  panel  on  Establishing  Management 
Objectives  analyzed  the  impact  of  a  DBMS  conversion  in  terms 
of  the  four  growth  processes  along  which  the  D.P.  function 
evol ves ,  namely : 

the  portfolio  of  computer  appl i cat  ions 

the  D.P.  organization  and  its  technical 
capabilities 

the  D.P.  planning  and  management  control  systems 
the  user 

Two  types  of  DBMS  conversions  were  addressed:  (1)  the 
initial  conversion  to  a  data  base  environment,  and  (2)  the 
conversion  from  one  DBMS  to  a  second  DBMS. 

Four  key  concepts  summarize  the  findings  of  the  panel: 

Conversion  to  a  data  base  environment  is  primarily  a 
question  of  how  soon  the  data  base  environment 
should  begin  to  be  constructed,  not  whether  a  data 
base  environment  should  be  implemented 
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Because  the  initial  data  base  application  represents 
an  important  learning  experience  for  the  entire 
organization,  great  care  must  be  exercised  in 
selecting  the  entry-! eve!  data  base  appl ication 

The  exposure  to  risk  associated  with  a  DBMS 
conversion  is  minimized  by  managing  the  conversion 
as  any  other  large  systems  project 

An  organization  will  likely  be  involved  in  multiple 
DBMS-related  conversions,  from  the  initial 
conversion  of  conventional  applications  to  data  base 
technology  to  the  conversion  of  applications  from 
one  DBMSto  a  second  DBMS.  Accordingly,  the  D.P. 
organization  should  plan  and  structure  for  future 
DBMS  conversions  now  in  order  to  minimize  the  impact 
of  future  conversions 


In  closing 
recognize  that 
probl em . 


appreciate   the   technology   involved,   but 
a   data   base   conversion   is   amana  gement 
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4.   ACTUAL  CONVERSION  EXPERIENCES 
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4.1   INTRODUCTION 


The  members  of  this  panel   reviewed   their   expe 
under   various  conversion  scenarios  to  identify  the  c 
factors  which  led  to  success  or  led  to  delays   and   f 
The   panel   felt   that   the   resultant   list   would 
managers  facing  data  base   conversion   projects.    Wh 
would   have   been    noteworthy   if   some   set   of 
methodologies,  etc.   had  emerged  from  the  experience 
group   which   would   make   any  future  conversions  e 
riskless,  the  panel  found  none.   In  the  panel's   opin 
successful   conversion  takes  tedious  preplanning  and 
execution;  and  in  the  current  state   of   practice   no 
panacea  exists. 


n  ences 
r  i  t  i  c  a  1 
ail u  r  e . 
benefit 
i  1  e  it 
tool s , 
of  the 
asy  and 
ion,  a 
careful 
known 


This  panel  will  not  try  to  tell  you  how  to  justify  data 
base  conversion  but  will  give  its  best  advice  on  what  to 
consider  when  approaching  the  conversion  task.  The  panel 
began  its  considerations  with  the  assumption  that  the 
justification  had  been  previously  determined.  The  panel 
agreed  that  its  experience  proved  conversion  justified.  In 
fact,  for  some  panel  members  conversion  was  unavoidable. 
Others  felt  they  had  demonstrated  the  value  of  conversion  to 
DBMS  but  with  some  reservations.  In  either 
experience  may  help  you. 


case ,   our 


TEN  CONVERSION  EXPERIENCES 


Scenarios: 

Manual  to  DBMS 
File  to  DBMS 
DBMS1  to  DBMS2 


6   1  involved  machine  change 
2    1  involved  machine  change 


Hardware : 

IBM  -Univac  -  Honeywell 

DBMS  Packages: 

IMS  -  TOTAL  -  DMS  1000  -  S2K  -  IDS  I  &  II 

Table  1:  Conversion  Experiences 
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The  panel  consisted  of  practitioners,  people  who  fought 
in  the  trenches  and  who  made  or  followed  decisions  to  use 
DBMS  techniques  in  actual  si tuat i ons--and  who,  in  most 
cases,  had  to  suffer  the  barrage  of  consequences. 

The  group  reviewed  only  recent   experiences,   although 
several   participants   have  been   using   the  concepts   and 
techniques  since  the  early  60's.   Table  1  presents  a  summary 
of  the  types  of  conversion  scenarios  reyiewed,  the  machines 
involved,  and  the  DBMS  variety. 

Specific  details  and  guidelines  that  resulted  from  the 
review  of  these  experiences  during  the  workshop  are  detailed 
below  in  the  section  called,  "ANNEX:  CONVERSION 
EXPERIENCES." 


4.2   PERSPECTIVES 
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However,  all  of  the  above  were  considered  subsidiary  to 
a  view  that  DBMS  controls  the  growth  of  information  in 
support  of  the  corporate  business  act i vi ties--wi th  less  pain 
and  suffering  for  all  participants. 


Many  also  see  DBMS  as  a  new  sequence  of  buzz  words 
acronyms:  schema,  root  segment,  subschema,  DDL,  DML;  a 
mystique;  a  new  barrier  between  the  ADP  community  and 
real  world.  As  an  industry,  we  may  yet  learn  that  grist 
the  Ph.D.  mill  and  true  payoff  to  the  business  world  are 
necessarily  the  same.  But,  the  boss  knows  it  and  suspects 
these  new  "academically  sponsored"  techniques.  Who  else 
invents  language  sounding  like  that  above? 
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And  as  usual,  the  new  technology  threatens  the   current 


technol ogists . 


Many  of  those  selling  DBMS  emphasize  the  "total" 
commitment  to  the  integration  possible  using  a  DBMS.  This 
convinces  management  that  DBMS,  more  than  a  new  risk,  means 
"total"  risk.  Who  would  make  a  decision  to  so  "expose"  the 
company?  Many  managers  hear  about  the  attributes  of  DBMS 
that  make  it  seem  a  new  technology  that  looks  good  for 
everything.  But  managers  have  seen  other  new  technologies 
with  similar  histories.  They  share  with  DBMS  the  following 
traits  : 

More  variants  seem  to  appear  daily 

No  one  seems  to  be  in  charge  of  standards,  or  even 
have  a  clue  on  how  to  start 

What  is  available  on  the  market  is  of  uneven 
qual i ty--ease  of  use,  reliability,  power  and  vendor 
support  seem  to  be  random  variables 

No  accepted  guidelines  on  "how  to  use"  and  "what  to 
avoid"  in  the  new  technology  seem  to  exist.  This 
disconcerts  managers. 

The  technology  conflicts  with  other  forces.  In  DBMS 
the  basic  principle  is  this:  the  corporation  should 
consider  its  data  as  a  central,  corporate  resource, 
not  a  private  resource  of  each  local  subunit.  At 
the  same  time,  it  is  clear  to  the  large  national  and 
international  corporations  that  local  authority  is 
the  only  way  to  inspire  local  responsibility. 

Confusion  over  the  fundamental  purpose  of  the  new 
technology.  It  is  not  clear  whether  the  advocates 
of  DBMS  are  technologists  trying  their  best  to  meet 
requested/perceived  needs  or  management  specialists 
who  see  an  opportunity  to  enforce  central  control. 
In  any  case,  DBMS  technology  claims  advantages  for 
the  user  whether  the  corporation  pursues 
centralized,  decentralized,  or  distributed 
responsibility,  authority,  or  data  processing. 
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4.3   FINDINGS 


The   panel   found    management's   attitude   about   data 
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The  first  commitment,  to  plan  for  the  use  of  data 
across  the  corporate  body,  is  clearly  a  new  job  that  is 
beyond  the  purview  of  any  single  department  and  also  beyond 
the  authority  usually  vested  in  the  data  processing 
department.  Anyone  trying  to  do  central  planning  faces  a 
struggle  because  each  private  domain  will  resist  change. 

Not  only  a  new  agent,  but  also  a  new  function  is  needed 
for  central  planning.:  Data  Base  Administration.  Performed 
at  two  levels,  this  function  may  not  be  under  a  common 
manager.  The  first  level  is  development/design  oriented. 
This  group  designs  the  data  base,  makes  available  the 
appropriate  tools  and  utilities,  analyses  the  usage  of  the 
data  base(s),  and  restructures  the  data  base.  This  group 
also  establishes  the  procedures  for  the  second  level,  the 
operation-oriented  Data  Base  Administrators. 

These  operation-oriented  Data  Base  Administrators  must 
deal  with  the  physical  aspects  of  the  data  base.  Such  old 
concepts  as  allocation  of  storage,  protection,  recovery, 
dumps,  verification,  etc.,  are  performed  in  quite  different 
ways  under  a  DBMS. 

Typical  figures  for  the  size  of  the  DBA  group  may  fall 
between  4  and  30.  Only  in  very  small  installations,  is  it  a 
one  man  job. 

The  panel  unanimously  warned  against  an  overambi tious 
project  size  for  the  initial  data  base  application.  This 
usually  results  in  errors  in  cost  and  time  estimates.  The 
anxious  user  withdraws  to  a  "wait  and  see"  mode  and 
announces  changes  in  his  needs  as  the  project  progresses. 
The  too-large  project  will  probably  be  unable  to  cope  with 
such  changes,  even  if  the  original  goals  are  successfully 
delivered.  All  of  this  leads  to  alienation  of  the  users  and 
managers  and  a  distinct  hesitation  to  continue  with  the  new 
application  technology. 

The  panel  noted  the  availability  of  packages  at  many 
levels.  However,  knowledge  of  how  to  best  choose  and  use  a 
data  base  system  is  in  short  supply  in  any  organization 
about  to  enter  the  data  base  world.  Help  from  both 
consultants  and  suppliers  is  available  and  should  be  used. 
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4.3.1  Industrial /Governmental  Practices. 

The  deliberations  on  pre-planning  and  planning 
identified  a  dichotomy  between  private  industry  and  the 
Federal  Government  in  both  the  processes  controlling  and  the 
results  accomplished. 

Industrial /Commercial  (I/C)  practice,  when  making 
decisions  on  hardware  and  support  software  (DBMS, 
Telecommunications,  etc.  packages),  requires  a  study  of  the 
alternatives  followed  by  negotiations  with  acceptable 
suppliers.  The  suppliers  would  be  asked  for  their  help  in 
determining  how  to  use  their  system.  I/C  firms  may  insist 
that  the  DBMS  and  other  packages  come  from  an  independent 
supplier  of  software. 

This  practice  allows  for  a  cooperatively  developed 
proposal  to  be  put  before  management;  one  in  which  each 
party  to  the  proposal  knows  his  role.  More  than  one  firm 
may  be  requested  to  make  such  a  proposal .  Outside 
consultants  who  are  familiar  with  the  various  aspects  of 
such  a  proposal  may  be  used  "to  keep  everybody  honest."  Such 
an  evaluation  may  take  nine  months  to  a  year,  but 
significant  preliminary  design  on  how  to  use  the  to-be- 
supplied  hardware/software  system  would  have  been  done. 

In  the  Federal  Government  practice,  whose  major 
procurement  dictum  is  maintenance  of  competition,  the 
selection  of  hardware  is  predicated  on  a  functional 
specification.  For  systems  to  be  implemented  in-house 
implies  a  hardware  functional  specification  to  permit 
various  subsystems  of  the  hardware  to  come  from  different 
vendors.  Specific  details  of  support  software  cannot  be 
specified  if  such  specification  gives  special  advantages  to 
only  one  vendor  or,  alternately,  eliminates  too  many 
competitors. 

At  best,  this  leads  to  a  watered-down  software 
specification  that  may  not  be  strong  enough  to  support  the 
intent  of  the  internal  Federal  Government  user.  At  worst, 
this  leads  to  a  strong  version  of  the  specification  such 
that  no  one  can  supply  as  an  off-the-shelf  software  system. 
Testing  such  a  system  will  take  place  long  after  selection. 
Systems  lacking  extensive  field  use  are  notorious  for  being 
unstable  and  poorly  matched  to  the  job  at  hand.  Examples  of 
such  systems  are  the  WWMCCS  and  the  ill  fated  ALS.  It  also 
means  that  non-vendor  developed  support  software  is  seldom 
bid  by  the  equipment  manufacturer. 
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In  terms  of  time,  this  system  of  procurement  produces  a 
one  or  two  year  procurement  process  which  requires  a 
benchmark  testing  period  oriented  to  some  standard  language. 
Such  benchmarks  cannot  take  special  advantage  of  a  vendor- 
specific  operating  systems  or  DBMS. 

After  the  hardware  is  selected,  the  internal  software 
group  must  do  a  preliminary  detailed  design,  using  the 
specific  hardware/software  selected  in  order  to  determine 
whether  the  original  requirements  can  be  met.  At  best,  this 
leads  to  an  additional  one  to  two  year  delay  over  industrial 
practice.  At  worst,  it  leads  to  a  squabbling,  contentious 
confrontation  between  two  groups  with  even  a  possibility  of 
law  suits,  threats,  and  ultimate  abandonment  of  the  original 
obj  ecti  ves . 

Buying  high  technology  from  an  adversary  point  of   view 

rather  than   a  mutually  cooperating   point  of  view  leads 

inevitably  to  extensive  delays  and  increased  costs--if  not 
to  outright  failure. 
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during  the  lag  in  the  Federal  Government 
,  several  things  occur.  The  problem 
As  noted  in  the  keynote  address, 
n  capacity  required  each  year  (stated  not 
omputation)  grows  10-20  percent  per  year, 
scouraged  and  cancels;  or  worse,  is  given 
xtract  new  promises  from  the  internal  ADP 
tion,  while  waiting  for  hardware/software 
rnal  ADP  team  must:   1)  Bide  its  time;  2) 

winner  and  proceed  concurrent  with 
band;  or  4)  assist  the  user  in  making 
e  first  is  wasteful,  the  second  is  risky, 
s  delay  and  confusion  after  selection  and 

to  extensive  over-commitment  of  both  the 
ware  and  the  internal  manpower. 


Thus,  the  panel  found  significant  differences  between 
I/C  and  Federal  practice.  While  the  differences  may  have 
much  larger  implications  they  also  increase  hardware  costs 
for  the  Federal  Government  when  buying  a  DBMS. 

A  way  to  avoid  some  of  the  difficulties  described  is 
for  the  federal  agency  to  create  a  truly  functional 
specification  in  the  user's  terms  and  to  ask  for  a 
competitive  turn-key  total  system.  This  will  eliminate 
third  party  sources,  etc.,  since  the  total  system  is  to  be 
procured  and  supplied  by  a  single  source.  However, 
upgrading  the  system  to  handle  additional  growth 
requirements  would  require,  at  best,  an  interim  upgrade  and, 
at  worst,  a  totally  new  procurement  process.  This  would  be 
anathema  to  a  concern  with  a  profit  motive.   Simply  stated, 
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cost-conscious  organizations  would  not  consider  the 
Government's  methods  to  be  good  business  practice. 


Federal 


4.3.2 
tor 
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DBMS  Installation. 


When 
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installing  a  DBMS 
time,  management,  user  and  service  supplier 
must  "get  its  feet  wet"  in  a  quick  and  successful  project. 
This  argues  for  phasing  implementations  into  small  packages 
deliverable  in,  at  the  most,  four  to  six  months.  This 
allows  each  group  to  develop  confidence,  give  feedback, 
adjust  its  plans  and  expectations  to  match  better  the  tasks 
at  hand  and  to  feel,  in  general,  comfortable  with  the 
changes . 

Installing  the  first  DBMS  will  result  in  changes  to 
lines  of  authority  and  responsibility,  some  real  and  some 
apparent.  Do  not  let  the  new  data  base  administrators  be 
stymied  by  the  old  war-lords.  Fiefdoms  exist  and  must  be 
continued  but  the  data  base  administrator  is  responsible  to 
the  organization  as  a  whole  and  needs  the  necessary 
authority  and  management  support.  Of  course,  this  new 
operating  mode  will  require  new  responsibilities  and 
corporate  approval  before  old  negotiated  responsibilities 
can  be  discarded. 

One  way  to  get  assistance  in  promoting  acceptance  of 
the  data  base  administrator  is  to  keep  the  communication 
lines  open.  This  enables  all  to  observe  the  changing 
environment,  to  get  frequent  statements  of  management 
support  for  the  data  base  administrator,  and  to  reaffirm  the 
resolve  to  continue  and  complete  the  desired  conversion. 

It  may  come  as  a  surprise  to  old  hands  in  the  business 
that  conversion  to  data  base  environment  from  either  a 
current  file  system  or  a  manual  system  will  each  require  a 
fault  tolerant  or  "forgiving"  mode  for  data  base  generation 
and  update.  Even  from  automated  files,  there  may  well  be 
illegal  values,  voids,  etc.  in  the  file.  This  could  cause  a 
significant  number  of  errors  to  be  found  by  the  edits  when 
building  the  new  data  base,  especially  if  internal  DBMS 
pointers  are  value  dependent. 

Your  users  will  need  help.  Do  not  "over  automate"  on 
the  initial  change  from  manual  files.  Use  the  current  data 
in  its  current  forms  to  meet  today's  needs.  Get  it  into  the 
data  base  and  clean  it  up  as  the  data  is  needed  for  new 
applications.  Cleanup  can  be  a  significant  and  unplanned- 
for  activity.  Accept  the  dirty  data  and  give  some  service 
of  value.  Do  not  take  the  position  that  it's  their  fault 
that  the  data  base  cannot  be  generated.   Help  them. 
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For  those  converting  already  automated  systems,  keep  a 
parallel  backup  for  each  full  system  conversion  until  the 
new  system  is  solid.   This  may  be  three  to  six  months. 

Try  scanning  a  file  for  range  of  values  on  an  item: 
illegal  or  nonsense  values  are  frequently  present. 

4.3.3  Desired  Standards. 

The  panel  regreted  the  lack  of  common  terminology  in 
the  data  base  management  arena;  indeed  it  appears  that  every 
new  development  of  any  size  brings  with  it  an  opportunity  to 
create  a  plethora  of  new  names  and  verbs  to  distinguish 
minor  variations.  The  underlying  fundamental  concepts  should 
be  given  standard  terminology  and  variants  clearly  explained 
and  justified. 

Conversion  tasks  would  become  easier  if  each  data 
management  system  had  the  same  functions  available,  or 
possibly  a  basic  subset  of  some  superset.  Common  functions 
with  common  definitions  would  create  the  same  result  for  the 
user,  even  though  the  implementations  varied.  This  may  be 
both  unachievable  and  undesirable,  given  the  several 
differing  fundamental  file  forms.  However,  it  may  be 
possible  within  classes  of  data  base  systems. 

A  third  useful  area  for  standardization  is  a  micro- 
language  (atomic  verbs)  in  which  the  functions  (commands)  of 
a  data  management  system  can  be  described  so  that  the 
detailed  specific  actions  of  each  command  are  obvious.  This 
would  make  definitions  more  clear  and  precise.  It  would 
facilitate  comparing  DBMS's  and  it  would  facilitate  re- 
implementation  of  a  DBMS  or  emulating  one  DBMS  with  another, 
an  action  which  might  be  needed  to  facilitate  changing 
hardware  and  DBMS. 

4.3.4  Desired  Technology. 

The  panel  saw  the  need  for  tools  to  assist  conversion 
from  one  DBMS  to  another.  Unfortunately,  they  might  have  to 
be  dependent  on  a  particular  situation  but  converting  one 
DBMS  file  to  another  should  be  possible  without  going  back 
to  transaction  mode  or  card  image  mode,  the  most  prevalent 
way  of  generating  a  data  base. 

Another  technology  development  needed  is  the  creation 
of  a  model  -  independent  data  description  that  could  be 
automatically  mapped  into  any  Data  Description  Language. 
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4.4   TOOLS  TO  AID  IN  THE  CONVERSION  PROCESS 


4.4.1  Introduction 
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4.4.2  Changing  From  Non-DBMS  To  DBMS. 
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The  transfer  of  data  from   inde 
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Moving  from  a  non-DBMS  to  a  DBMS  environment  involves, 
in  most  cases,  a  matching  of  like  functions  in  many 
independent  application  programs  to  shared  functions  in  the 
DBMS.  Consequently,  this  movement  involves  removing  code 
from  the  application  programs  and  replacing  it  with  code  to 
interface  with  the  DBMS.  The  bulk  of  application  dependent 
code  should  remain  the  same.  Capabilities  such  as 
backup/recovery  and  physical  data  structuring  will  be  moved 
as  a  whole  to  the  DBMS.  In  the  DBMS  environment,  no 
capabilities  are  lost  to  the  application  programs--onl y 
gained. 

No  tools  are  currently  available  to  aid  in  this 
transfer  of  capabilities,  but  all  DBMS  share  a  common 
repertoire  of  functions  to  include  facilities  for  data 
creation,  update,  and  deletion.  These  capabilities, 
however,  vary  depending  upon  the  underlying  conceptual  model 
of  the  DBMS.  Standardization  of  DBMS  capabilities  and 
syntax  could  allow  for  a  more  complete  predesign  effort 
through  knowledge  of  system  features. 
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As  mentioned  earlier,  conversion  forces  management  to 
take  a  much  tighter  control  by  establishment  of  a 
centralized  function  known  as  Data  Base  Administration 
(DBA).  Within  the  DBA  function,  procedures  are  further 
established  to  deal  with  data  integrity,  accessibility, 
confidentiality,  and  miscellaneous  control.  The  primary 
tool  of  the  DBA  is  "clout"  or  having  a  position  in  the 
organization  with  the  authority  and  responsibility  to  ensure 
the  compliance  with  established  procedures.  The  DD/D  is 
also  used  by  the  DBA  to  aid  in  the  design,  implementation, 
and  maintenance  of  the  data  base. 
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In  migrating  data  to  the  new  environment,  no  new 
problems  will  be  encountered  which  have  not  previously  been 
discussed.  The  download  programs  should,  however,  already 
be  developed  for  such  purposes  as  data  base  archiving 
(dumpi  ng) . 

The  transfer  of  capabilities  provides  the  greatest 
impact  on  the  conversion  between  dissimilar  DBMS.  DDL 
presents  the  first  difficulty  in  conversion.  In  order  to 
implement  the  new  data  base,  some  description  of  the  new 
data  base  structure  must  be  developed  in  the  target  DDL. 
Automated  translation  tools  can  be  developed  if  the  source 
DDL  is  extensive.  Manual  translations,  however,  seem  more 
appropriate  due  to  various  changes  in  the  way  in  which  DDL 
may  be  interpreted;  e.g.,  DATA  SET  in  DMS-II  is  not  the  same 
as  DATA  SET  in  IMS. 
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A  DML,  as  mentioned  earlier,  offers  the  most  advantages 
to  automated  translation  when  the  interface  syntax  is  fixed 
(CODASYL's  DML).  When  the  interface  is  purely  through 
dynamically  built  character  strings  (IMS,  TOTAL)  automated 
conversion  can  only  replace  CALL  statements  of  one  format  to 
CALL  statements  of  another.  The  DML  functions,  although 
common  (GET,  PUT,  CREATE,  DELETE,  UPDATE),  also  vary  in 
interpretation.  An  example:  FIND  in  a  CODASYL-like  DBMS 
only  locates  a  record  as  stated  in  the  record  selection 
expression  and  a  subsequent  GET  must  be  issued  to  load  the 
data  into  the  issuing  program's  work  area.  A  GU  (get 
unique)  in  IMS  not  only  accesses  a  record  but  also  requires 
the  Segment  Selection  Argument  (SSA)  to  find  the  appropriate 
record.  Therefore,  the  capability  of  a  single  DML  command 
may  not  be  replaceable  by  another  single  command  of  the  new 
DBMS.  Conversely,  several  commands  which  span  both  DDL 
and  DML  (record  selection  expression/set  selection)  in  a 
CODASYL-like  DBMS  may  be  replaceable  by  one  command  (GU 
W/SSA).  Other  commands  of  the  source  DML  may  not  be 
duplicated  in  the  DML  of  the  target  DBMS.  Apart  from  the 
DDL  and  DML  capabilities,  more  basic  differences  may  exist. 

Shared  functions  which  DBMS  supply  are  often  quite 
different.  Where  one  DBMS  may  supply  item  level  locks, 
another  may  make  only  record  or  data  base  locks  available. 
Access  controls,  recovery,  and  auditing  are  just  a  few  of 
the  support  capabilities  which  vary  between  DBMS,  even  those 
which  implement  the  CODASYL  specifications.  The  change  in 
capabilities,  therefore,  is  indeed  the  most  evident 
conversion  problem  in  migrating  applications  between 
di  ssimi 1 ar  DBMS. 
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4.4.6  Centralized  DBMS--di stributed  DBMS. 
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4.5   GUIDELINES  FOR  YOUR  FUTURE  CONVERSIONS 

The  panel  concluded  that  the  single  most  important 
guideline  to  offer  a  group  about  to  embark  on  a  system 
conversion  wasto  use  thei r  best  management  techniques.  It  is 
a  technically  difficult  job,  like  most  large  software  system 
developments,  and  one  must  apply  all  well-known  software 
development   methods. 
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4.5.1  General  Guidelines.  The  discussion  of  the  various 
conversion  scenarios  revealed  the  fact  that  several 
management  practices  had  been  utilized  in  all  of  the 
successful  conversions  which,  though  common  across  all  data 
processing  environments,  were  of  particular  relevance  in  the 
data  base  environment  where  problems  and 
establishing  policy  proliferate  across  all 
ut il i  zi  ng  the  DBMS. 


errors   in 
appl i cat  ions 


4.5.2  Important  Considerations. 

.  Analyze  all  possible  file  organizations.  Do  not 
assume  that  the  most  efficient  way  is  going  to  be  a 
data  base.  Some  applications  can  perform  better 
using  sequential  files  such  as  tapes  or  other  access 
methods  such  as  Index  Sequential. 


Analyze  the  final  stages  of  the  conversion, 
will   you  convert  to  production?   Will  it  be  (or 
it  be)  converted  module  by  module,   transaction 
transaction,   or  will   it  be  necessary  to  "push 
button"  and  convert  to  production  all  at  once? 


How 

can 

by 

the 


Develop  a   representative  model  of  the   company's 

business   for  design   purposes.  This  model  should 

provide  the  basis  for  the  design  of  the  data  base 
which  will  be  in  production. 

Determine  the  degree  of  security  and  integrity 
required  for  the  operation  of  the  data  base.  Who 
will  have  access  to  certain  information?  How  will 
unauthorized  use  be  prevented?  How  will  you  recover 
or  reconstruct  the  data  base  in  the  event  of  a 
software  or  hardware  failure? 


Determine  the  space  requirement  for  the  production 
data  base.  Determine  if  all  the  data  on  the  file  is 
necessary  and  is  being  used.  Check  for  redundant 
data.  (It  is  not  always  bad  to  have  redundant  data, 
especially  if  it  will  improve  retrieval  time.) 


Build  a  small 
deficiencies 


version  of  the  data  base  and  test  for 
in  the  design  or  in  the  modules.  The 
testing  must  be  thorough  and  cover  all  facets  of  the 
company's  business.  Users'  involvement  in  this 
stage  should  be  heavy  but  should  not  dictate  how  the 
data  base  is  to  be  designed  or  what  access  methods 
must  be  used. 
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Determine  whether  a  Data  Base  Administrator  is 
needed  for  your  organization.  The  DBA  will  be 
responsible  for  the  security  and  integrity  of  the 
data  base  (including  recovery  and  backup)  and  act  as 
an  agent  between  the  User's  group  and  the  data 
processing  group. 

Determine  the  type  of  support  you  will  need  from  the 
vendor.  Will  classes  be  given  on  data  base 
technology?  Will  the  vendor  be  readily  available 
when  a  problem  arises?  Contact  various  users  in 
your  area.  Attend  a  local  users  group  meeting  and 
find  out  the  types  of  probl ems  and  solutions  that  the 
group  has  come  up  with,  especially  talk  to  users  in 
the  same  type  of  business.  Valuable  information  can 
be  obtained  and  you  will  not  re-invent  the  wheel. 

Determine  how  eager  upper  management  is  to  undertake 
the  task  of  converting.  If  they  support  you,  the 
task  will  be  easier  and  more  efficient. 

Look  into  the  future.  Determine  whether  the  present 
design  of  the  data  base  is  the  most  efficient  one  in 
case  new  applications  are  introduced.  Do  not  be 
afraid  to  redesign  if  it  proves  to  be  more 
efficient.  Provide  for  a  purge  of  unneeded  data. 
Reorganize  the  data  bases  on  a  regular  basis  to  re- 
claim unused  space  or  to  compact  the  data.  One  very 
large  data  base  may  not  be  feasible. 


Determine  whether  to  use   standard 
software  or  develop  you  own. 


vendor   supplied 


Once  a  decision  has  been  made  to  convert  to  a  DBMS, 
check  and  re-check  for  contract  to  be  signed.  Have 
a  contract  attorney  study  the  agreement. 

4.5.3  Ti  ght  Control  .  In  successful  conversion  efforts, 
special  emphasis  must  be  placed  on  establishing  procedures 
and  policies  and  insuring  that  they  are  followed.  Examples 
of  these  procedures  and  policies  include  internal  standards, 
data  base  administration,  and  explicit  (precisely  defined) 
goal s . 

4.5.4  Precise  PI anning/ pre-pl ann i ng  .  The  probability  of  a 
conversion  succeeding  is  directly  proportional  to  the  degree 
of  preparation.   Preplanning  efforts  involve: 


establishing   current   baselines   and 
perceived  inadequacies 


ident i  fyi  ng 
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.   defining  requirements  or   specifying   what   are   the 
desires  of  the  conversion 

enumerating  as  many  alternatives  as  practical  and 
determining  their  appropriateness  in  the  target 
environment 

establishing  feasibility  in  terms  of  costs,  people, 
and  time 

describing  milestones  and  benefits 

receiving  and  documenting  a  management  commitment  to 

a  specific  alternative 

t 

Planning  efforts  must  begin  immediately  upon  management 
commitment  and  include: 

organizing  for  the  project 

defining  support  software  requirements 

evaluating  available  systems  (packages) 

describing  selection  criteria 

selecting  and  procuring  software 

building  a  well-defined  implementation  plan 
including  staffing,  training,  detailed  design,  and 
implementation  strategy 

seeking  final  plan  coordination  and  approval 

4,5.5  Important  Actions.   The   panel    recommended    several 
act  1 ons : 

Do  Establish  Review  Points.  When  describing  a  plan, 
care  must  be  taken  to  ensure  flexibility  in  order  to 
support  changing/overlooked  requirements.  Points 
must  be  scheduled  at  which  time  the  plan  is  reviewed 
and  updated  as  required.  Decisions  must  also  be 
made  as  to  the  appropriateness  of  proceeding  with 
devel opment . 

Do  Involve  End  Users.  The  data  processing 
department  must  be  extremely  careful  not  to  ignore 
user  input  to  the  development  process.  No  one  knows 
the  functional  requirements  which  must  be  met  better 
than  the  end  user. 
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Do  Keep  Scope  Reasonable.  The  scope  of  the  project 
must  be  dictated  by  practicality.  Attempt  only  as 
much  as  is  attainable  within  well  defined  time 
frames  and  technology.  Once  the  scope  is  defined, 
stay  within  its  bounds. 


Do  Not  Stifle  Prototyping, 
best   method    available 
Encourage    validation 
prototyping. 


Modeling  is  perhaps   the 

for   trying   out   ideas. 

of    concepts    through 


Do   Shift   Responsibility  to   Where   the   Expertise 

Exists.    Always   ensure  that   responsibility   for 

achieving  goals  is  placed  where  the  ability  to   both 

understand  and  accomplish  them  exists. 

Do  Phase  the  Implementation.  Within  an  overall 
context,  ensure  that  total  system  conversion  is 
planned  and  executed  in  attainable  increments. 

Be  Wary  of  Entanglements.  System  conversion 
planners  must  always  review  commitments  with  the 
goal  of  avoiding  crippling  dependence  upon 
manufacturers,  proprietary  packages,  and  maintenance 

Recognize  Costs/Benefits  of  New 
Quantify  both  the  advantages  and 
of   being   the   first   to    use   new 


agreements . 
Technol ogy . 
di  sadvantages 
technol ogy. 


Do  get  adequate  management  commitment.  Make  sure 
management  knows  beforehand  what  resources  and  time 
periods  are  required,  what  has  been  available,  and 
what  progess,  if  any,  has  been  made.  Do  not  let 
them  walk  away  from  it.   They  are    key  players. 

Do  initially  select  an  important  but  tractable 
portion  of  the  ultimate  and  have  some  results  in 
four  to  six  months.  This  forces  a  early  and 
realistic  review.  One  also  hopes  it  demonstrates  the 
new  capabilities,  emphasizes  the  ability  of  the 
implementors  to  handle  the  new  technology,  and 
provides  better  insights  into  both  the  technical  and 
operational  (people  oriented)  problems  that  the 
organization  will  face. 

Do  introduce  your  technical  staff  to  the  new 
technology.  First,  when  you  are  studying  whether  to 
go  data  base  but,  also,  immediately  before  and 
during  the  initial  implementation.  Sometimes  six 
months  to  two  years  pass  from  initial  study  to  start 
of  implementation.  Further,  training  for  the 
initial  decision  process  is  usually  "book   learning" 
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and  quite  stale  by  implementation  time. 


your   users.    Next 
the  key  to  success. 

That 


to 

They 

means 


Do  orient  and  educate 
management,  this  group  is 
must  feel  comfortable  with  what  you  say 
they  should  have  a  role  in  deciding  what  they  get 
and  when.  In  addition,  they  must  prepare  themselves 
for  the  new  modes  of  operation. 


Do  keep  the  user  group  on  your  management  review 
team.  They  can  keep  you  out  of  trouble.  They  can 
change  their  priorities  and  needs  to  fit  your 
capabilities  to  deliver.  They  can  help  you  resist 
pressures  for  early  and  extra  delivery  since  they, 
too,  want  and  need  a  quality  product.  By  keeping 
them  in  the  loop,  you  risk  less  chance  of  surprising 
them  and  evoking  resistance  on  delivery. 
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Do  ask  for  and  accept  help  from  the  vendor  of  the 
data  base  system.  If  you  are  also  changing  hardware 
at  the  same  time,  put  pressure  and  some  of  the  risk 
on  that  vendor.  Good  advice  must  be  available  during 
your  learning  period.  Consultants  are  useful,  not 
only  initially,  but  also  during  design  and 
implementation  time. 


4.6   REPRISE 

The  most  significant  finding:  the  ingredients  for 
success  are  management  commitment  and  discipline,  skilled 
people,  clear  roles,  and  lots  of  cooperative  conversation 
between  the  parties  involved.  Not  a  new  discovery  but  still 
signi f icant--and  more  essential  than  ever  at  this  stage  in 
DBMS  evol ut ion  . 


4.7   ANNEX:  CONVERSION  EXPERIENCES 


4. 7. 1  Conversion 
whi  ch 


File  To 

TTTus  t  rate 


DBMS.  The  three  user 
to  I  I ow 
file  system  environment  to  a 


change  in  hardware  resources. 


experiences 

the  scenario  of  converting  from  a 

data  base  environment  without  a 


Conversion  Experience  -  A . 

Goal s.  Studies  were  conducted  to  analyze  the  problems  of 
the  file  environment.  Problems  identified  by  the  functional 
user  and  data  processing  departments  included  prohibitive 
maintenance  and  enhancement  costs,  slow  implementation  of 
additional  user  requirements,  heavy  data  and  processing 
redundancies,  and  lack  of  data  integrity. 

Summary  of  actions .  The  problems  described  in  the  previous 
section  "Ted  to  the  data  base  decision.  Following  this 
decision,  a  consulting  firm  prepared  a  data  base  conversion 
plan  to  execute  those  tasks  in  the  plan  leading  up  to  but 
not  including  the  conversion  of  data  or  application  systems. 
A  directory  of  steps  and  tasks  in  the  data  base  system  plan 
that  the  consulting  firm  prepared  follows. 

Evaluate  the  Present  Information  System 
Information  Flow  Analysis 
Current  ADP  Analysis 
Current  Reports  Analysis 
Status  of  Present  Information  System 
for  Data  Base 

Draft  of  Data  Base  Administration 
Res  pons ib  il i  ti  es 


Step 

L: 

Task 

1, 

.1 

Task 

1 

,2 

Task 

1 

.3 

Task 

1 

.4 

Task  1.5 
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Step  2:   Define  Data  Base  Requirements 
Task  2.1   Service  Analysis  Development  by  Report 
Task  2.2   Service  Analysis  Development  by  Function 
Task  2.3  Data  Dictionary  Development 

Step  3:   Develop  Initial  Data  Base  Architecture 
Task  3.1   Distribute  Data  Dictionary  Elements 
Task  3.2  Distribution  Optimization 
Task  3.3  Architecture  Description 

Step  4:   DBMS  Package  Evaluation  and  Recommendation 
Task  4.1   Architecture  Mapping 
Task  4.2   Support  Features 
Task  4.3   Secondary  Features 
Task  4.4  Recommendation 

Step  5:   Application  Redesign 
Task  5.1   Design  and  Program  Documentation 
Task  5.2   Structured  Programming  Analysis 
Task  5.3   Implementation  Controls 

Step  6:   Configuration  Analysis  and  Evaluation 
Task  6.1  Current  Load  Analysis 
Task  6.2   Future  Load  Analysis 
Task  6.3  Simulation  Modeling 
Task  6.4  Simulation  Analysis 

Step  7:   Implementation  and  Conversion  Plan 
Task  7.1  DBMS  Installation  Planning 
Task  7.2  Data  Conversion  Planning 
Task  7.3  Application  Conversion  P-lanning 

Step  8:   Personnel  Development  and  Training 
Task  8.1   Assess  Available  Talent  Levels 
Task  8.2  Develop  a  Formal  Training  Plan 

During  these  tasks  the  consulting  firm  provided  project 
direction  and  DBMS  expertise.  Company  personnel  assigned  to 
the  project  received  practical  training  while  preparing  tor 
planned  conversion  of  application  software  and  data  files. 

Some  points  should  be  noted  about   the   tasks   prepared 
for  the  data  base  system  plan: 

.   The  evaluation  of  the  results  from  tasks  1.1  through 
1.4  was  used  to  support  the  data  base  decision. 

The  data  base  administration  function  was 
established  following  a  draft  of  responsibilities 
prepared  in  task  1.5. 
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The  initial  data  base  architecture  described  in  task 
3.3  was  package  independent. 
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DBMS  package  recommended  in  task  4.4  was 
need  by  constraints  imposed  on  the  evaluation 
s.  The  influences  included  the  need  to 
ace  with  teleprocessing  and  the 
1  DBMS  with  an  initial  or  pilot 
conversion   in  just  four  months. 


abil i  ty   to 
application 


application  conversion  plans  in  task  7.3 
fied  functional  redesign  requirements 
ing  from  the   service  analysis  conducted   in 

2.2  to  correct  deficiencies  in  existing 
re  and  to  benefit  from  the  facilities  offered 

DBMS  package. 


At  this  time  the  recommended  DBMS  is  installed  and  the 
conversion  and  implementation  of  the  pilot  application 
system  and  its  data  files  to  data  base  is  completed.  The 
conversion  effort  was  successful  but  not  without  its 
problems.  The  functional  user  organizations  feel  the 
benefits  of  DBMS  in  the  areas  of  performance,  data  integrity 
and  responsiveness  on  the  part  of  the  data  processing 
department  to  change  requests.  However,  further 
implementations  to  DBMS  are  suspended  due  to  a  redefinition 
of  priorities  outside  the  data  base  system  plan. 

Cone! usions.   Factors  contributing  to  the   success   of  that 
conversion  or  to  the  problems  that  occurred  were: 

Management  demonstrated  commitment  by  the  funds  made 
available  for  consultant  services,  by  the  investment 
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resources  only  aggravated  the  political  problem.  As 
such,  the  establishment  of  the  DBA  function  was  less 
than  effective.  The  influence  of  such  political 
struggles  on  the  suspension  of  further  data  base 
conversion  activities  is  difficult  to  determine. 

A  major  problem  in  converting  from  a  non-data  base 
environment  to  data  base  is  that  during  the  period 
when  data  base  expertise  is  critically  needed,  you 
are  least  able  to  provide  it.  This  problem  was 
eliminated  with  the  expertise  provided  by 
consul tants . 

The  placement  of  the  DBA  within  the  data  processing 
organization  and  the  limitation  of  its 
responsibilities  contributed  to  the  lack  of  support 
at  the  right  level  of  management  for  continuation  of 
the  data  base  project.  This  was  very  much  in 
evidence  when  staff  meetings  were  conducted  to 
prioritize  data  processing  activities. 

The  benefits  realized  by  the  conversion  and 
implementation  of  the  pilot  application  system 
resulted  from  the  redesign  activities.   However,  the 

analysis  was  instrumental  in 
pilot  system  that  had  low  risks,  early 
visibility.  These  three  factors  alone 
save  the  future  of  the  data  base 
project  in  the  context  of  further  implementations  of 
data  base.  Once  a  data  base  conversion  effort  is 
suspended,  it  normally  takes  support  from  the  user 
community  to  reactivate  it. 


cost/benef i  t 
identifying  a 
benef i  t s ,  and 
may  very  well 


Problems  encountered  during  the  conversion  process 
were  due,  for  the  most  part,  to  inadequate  training 
of  people  in  the  usage  of  the  DBMS  and  in  the 
interpretation  of  its  diagnostics.  The  amount  of 
training  planned  was  reduced  in  an  effort  to 
compensate  for  an  insufficient  number  of  people  made 
available  to  convert  the  pilot  system. 

Conversion  Experience  -  B_. 

Goal  s.  The  experience  involved  choosing  and  using  a  DBMS  to 
support  processing  of  solar  hardware  system  data.  The  solar 
hardware  data  resided  in  file  format,  yet  structural 
relationships  existing  between  and  among  data  records  could 
not  be  supported  in  any  reasonable  manner  in  the  file 
oriented  environment.  In  addition,  many  of  the  user 
requirements  were  not  adequately  defined  and  there  was 
considerable   worry  about   whether   the   known  requirements 
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could  ever  be  met. 
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Although  unanswered  questions  remained  regarding  the 
feasibility  of  this  approach,  many  desirable  aspects  were, 
on  the  other  hand,  apparent.  The  DBMS  selected  was 
available  in  a  bundled  form  from  the  hardware  vendor  —  no 
additional  costs--and  the  software  could  be  delivered  in  a 
timely  manner.  In  addition,  the  selected  DBMS  supported  the 
required  structural  relationships  with  its  CODASYL 
orientation. 

The  best  understanding  of  what  output  requirements  the 
DBMS  should  provide  was  used  to  design  the  data  base  and 
implement  application  programs.  All  of  the  requirements 
were  met  in  a  reasonable  time  within  reasonable  costs. 

Cone! usions.   Critical  points  in  the  success   of   this   DBMS 
conversion  experience  were: 


DBMS  expertise  was  available  from  the  beginning--a 
most  important  time  in  any  DBMS  environment. 

The  users  participated  in  defining  the  information 
processing  requirements. 

Expertise  was  available  in  matching  information 
processing  requirements  to  available  DBMS 
capabil ities. 

The  vendor  provided  adequate  training  and  sufficient 
time  to  gain  experience  after  the  training  was 
completed.  This  provided  the  necessary  insights 
into  the  actual  capabilities  of  the  chosen  DBMS. 

Portions  of  the  output  requirements  were 
sufficiently  well  documented  and  were  of  reasonable 
magnitude  to  demonstrate  successful  operation  of  the 
DBMS  demonstration. 
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Conversion  Experience  -  C_. 


Goal  s 


To  convert  a  large  number  of  antiquated  files  to  the 
state-of-the-art  technology. 

To  provide  for  a  more  efficient   way  of  retrieving 
and  updati  ng  data . 

To  eliminate  redundancy  through  a   centralized   data 
bank  . 

To   eliminate   erroneous   information   through  data 
integrity. 

To  provide  better  management  of  information. 

To  provide  for  more  system  security. 


one  alternative  was  available 
to  a  DBMS  and  at  the  time  only 


Summary  of  actions.   Only 

convert   existing   files 

DBMS  could  meet  the  requirements  set  by  upper  management 
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with  its  own  higher  level  language  interface  was  chosen. 
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Another  problem  resulted  from  personnel  assignments. 
While  one  group  was  loading  the  data  base,  another  was 
testing.  The  group  that  loaded  the  data  base  did  not  have 
as  good  an  understanding  of  content  as  the  testing  group. 
Consequently  erroneous  data  was  loaded.  If  both  groups  had 
worked  more  closely,  most  of  these  problems  would  have  been 
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resol ved . 

Cone! us  ions .   The  following   points   are   characteristic   of 
successful  conversions  in  the  described  scenario: 


1.  Management  commitment  ensures  sufficient  resources 
and  end  user  support  of  the  conversion  effort. 

2.  DBMS  expertise  must  be  available  from  the  beginning 
of  the  conversion  effort. 

3.  Adequate  preplanning  and  planning  activities  are 
instrumental  in  the  conversion  to  data  base. 

4.  The  end  users  must  participate  in  defining 
information  processing  requirements. 

5.  The  DBA  support  must  be  a  strong  and  continuing 
commi  tment . 

6.  In  the  DBMS  package  evaluation,  expertise  must  be 
available  to  match  the  information  processing 
requirements  to  the  capabilities  of  available  DBMS 
packages . 

7.  Adequate  and  timely  training  must  be  provided  and 
sufficient  hands-on  experience  must  be  gained  prior 
to  any  conversion  of  application  software. 

8.  A  conservative  staging  plan,  one  which  selects  an 
application  system  for  initial  implementation  that 
offers  low  risks,  high  benefits  and  visibility,  must 
be  developed  to  insure  continuing  resource  support. 

9.  The  DBMS  conversion  must  be  thoroughly  and 
adequately  tested  prior  to  the  production  cycle.  A 
fall-back  procedure  should  be  established  in  the 
event  that  the  conversion  is  not  successful. 


4.7.2  Co n v e r s i  o n 
represents 


Manual  Environment  To  DBMS.  This 


scenario 
conversions  in  wnTcTT  cTafa"  Ts  maintained  and  used 
manually  in  the  source  (old)  environment  and  it  is  desired 
to  convert  the  data  and  functions  directly  to  a  DBMS  without 
first  introducing  a  non-DBMS  file  system. 


Conversion  Experience  -  A . 

Goal s.  The  goal  of  this  conversion  was  to  mechanize 
functions  performed  manually  by  separate  operating 
departments  using  the  same  input  documents.  The  input 
documents  triggered  each  of  these  departments  to  perform  its 
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own  -functions  using  i ts  i ndi vidual  ,  manually-maintained  data 
records.  The  flow  of  the  input  documents  went  from  one 
department  to  another.  The  flow  was  sequential  in  nature 
since  one  department  had  to  complete  its  function 
next  could  begin.  Each  department  independently 
its  own  data  records.  The  records  in  each 
contained  some  common  data  components. 


before  the 
mai  ntai  ned 
department 


This  total  process  had  never  been  mechanized  before 
because  of  the  complexity  of  the  operations  involved  and  the 
lack  of  data  structures  to  represent  the  interrelations  of 
the  data  and  functions.  DBMS  technology  made  mechanized 
processing  and  a  common  data  storage  place  feasible. 

The  expections  of  mechanization  included: 

1.  Better  performance  of  end-user  functions  through 
more  accurate  records  and  increased  capability  of 
machine  over  human  operation. 

2.  More  efficient  performance  of  functions  through 
elimination  of  duplicate  record  keeping  and 
mechani  zation . 

Summary  of  actions.  The  project  selected  a  network  DBMS 
i  ncl uding  full  communications  and  transaction  management 
capability.  Interactive  terminals  were  designated  for  end 
user  locations  as  well  as  an  interface  developed  with  a 
front-end  system  controlling  the  flow  of  the  inputs  to  the 
system  and  the  distribution  of  the  outputs  to  the 
appropriate  user  departments  and  to  other  mechanized 
systems . 

The  conversion  from  a  manual  environment  to  the  full 
DBMS  has  been  completed  successfully  at  one  site  and  the 
DBMS  has  been  operational  for  several  years.  During  this 
time,  more  sites  have  been  converted  to  the  system. 
Interfaces  between  this  system  and  other  DBMS  systems  are 
being  developed.  Since  these  interfaces  are  not  yet 
operational,  conclusive  findings  cannot  be  stated. 

Concl usions.  The  task  of  interfacing  two  DBMS  should  not  be 
underestimated,  especially  if  the  systems  use  different 
software  or  hardware.  For  example,  plenty  of  time  should  be 
allocated  in  developing  the  interface  simply  to  work  out  the 
kinks  of  reading  data  created  by  another  DBMS  in  a  language 
with  a  different  bit  structure  and  character  set. 

When  an  interface  is  first  developed  between  two 
systems,  time  must  also  be  allotted  to  resolving  differences 
in  how  one  system  identifies  or  names  what  are  thought  to  be 
common   data   elements.    Both   systems  may  process  the  same 
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widgets,  but  one  may  be  concerned  with  inventory  and  the 
other  with  maintenance  or  repair.  Both  systems  can  be 
involved  with  some  of  the  same  widgets,  but  the  way  they 
identify  or  represent  them  may  be  different.  These 
differences  may  not  be  apparent  or  may  seem  trivial  until  an 
actual  mechanized  interface  is  attempted. 

Merely  because  there  could  be  a  mechanized  link  between 
two  systems  does  not  mean  there  should  be  such  a  link.  It 
may  be  far  more  economical  to  use  a  manual  interface, 
especially  for  low  volume  interactions  or  in  cases  where  the 
viewpoints  of  the  two  systems  differ  greatly. 

Environments  with  multiple  DMBS  are  very  frustrating  to 
users  if  these  DBMS  each  use  different  input  devices  with 
different  sign-on  procedures  and  modes  of  interaction. 

Coordination  and  planning  between  the  DBMS  in 
development  are  needed  to  prevent  proliferation  of  different 
terminal  equipment  at  the  same  user  locations. 


Conversion  Experience  -  B_. 

Goal s.   The  goal  of  the  project  was 
document  retrieval  system. 


to   automate  a  manual 
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After  the  software  conversion  started,  analysis  made  it 
apparent  that  the  capture  of  the  manual  data  in  a  machine- 
readable  form  would  require  about  twelve  staff/years.  Also, 
on-going  entry  of  new  documents  and  servicing  users  would 
have  required  a  permanent  staff  of  4-5  people.  Attempts  to 
convince  management  of  these  needs  were  unsuccessful. 

The  events  that  followed  were: 
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A  successful  software  conversion  followed  by 
augmentation  of  the  converted  software. 

Design  of  procedures  and  entry  forms,  and 
identification  of  resources  needed  to  capture  the 
manual  files. 

Shelving  of  the  project  because  resources  were  not 
available  to  either  contract  the  data  capture  or  to 
staff  it  in  house. 

Cone! usions .  While  not  a  conversion  to  a  true  DBMS,  this 
experience  illustrates,  by  their  absence,  several  points 
necessary  for  DBMS  conversions. 

Importance  of  planning  and  analysis  before  any 
decisions  are  "cast  in  concrete." 
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Importance  of  obtaining  a  commitment  of  resources 
sufficient  for  the  entire  project  before  starting 
any  part  of  it.  In  this  case,  the  decision-makers 
had  no  comprehension  of  what  would  be  involved. 
Neither  the  one-time  data  capture  nor  the  on-going 
support  staff  needed  could  be  had  when  the  time  came 
to  actually  implement  the  retrieval  system  and 
service  customers  with  it.  Therefore,  extensive 
conversion  and  analysis  were  wasted. 

Recommendati  ons . 

The  manual -to-DBMS  conversion  situation  has  two 
characteristics  which  make  it  unique  among  the  Data  Base 
conversion  situations: 

1.   Data  not  already  machine-readable 
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2.   Users  not  accustomed  to  automated  systems 

Consequently,  those  contemplating  such  a   conversion   should 
take  the  following  actions: 

Develop  implementation  strategy.   Purpose:   Control  cost  and 
meet  schedul e . 

Limit  scope.  It  is  necessary  to  limit  the  scope  of 
the  conversion  to  something  manageable  and  do-able. 
Limit  objectives  to  high- volume,  high- usage 
functions.  Do  not  try  to  automate  low-usage  and/or 
exception  cases.  Stick  to  your  initial  limited 
scope.  Do  not  be  tempted  to  agree  to  ad  hoc 
extensions  of  scope.  Prioritize  and  save  good  ideas 
for  future  enhancements. 

Plan  on  phased  implementation.  Get  something  useful 
up  soon.  (Your  limited  scope--above--shoul d  have 
selected  a  useful  small  application.)  Getting 
something  into  actual  use  soon  will: 

Let  the  customer  see  benefits  early  and  provide 
experience  on  the  system 

a.  Gives  the  project  team  some  feedback  early 

b.  Buys  the  project  team  some  credibility  with  users 
for  later,  larger  projects 

Plan  on  re-implementing.  The  first  limited-scope 
appl ication( s)  will  very  likely  benefit  from  later 
re-implementation. 

Select  initial  installation/site  carefully.  Give 
yourself  the  best  chance  of  success.  If  the  system 
is  planned  for  several  sites,  do  the  easiest  one 
f  i  rst . 


Understand  magnitude  of  data  capture  and  data  cl eaning 
effort .'  Everyone,  TncTuding  top  management,  must  understand 
that  capturing  the  data  and  correcting  it  will  be  a  'large' 
effort.  This  effort  is  a  significant  part  of  overall 
project  costs;  it  may  be  the  largest. 


It  should  be  understood  and  budgeted  for  at  the 
beginning.  Sampling  the  manual  data  for  accuracy  and 
completeness  is  useful  in  estimating  the  resources  needed 
for  data  capture  and  correction. 

Resolve  political  problems  of  ownership  of  data. 
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Source.  Where  the  data  is  kept  by  several 
organizational  divisions,  determine  which  one  is  the 
best  source  for  the  application  you  are  converting. 


to  be   responsible 


Discrepancies.  Designate  someone 
for  resolving  discrepancies. 

missing  data  elements 
incorrect  data  elements 
Obsolete  data  elements 

These,  of  course,  are  familiar  functions  of  the  DBA. 
Such  problems  are,  however,  magnified  in  a  situation  where 
there  has  been  no  automation  before. 

In  vol ve  users  earl y .   Early  end  user  involvement  can: 

Get  some  support  for  the  project  team 

Give  end  users  time  to  identify: 

Changes  to  their  work  flow 
Changes  to  staff  requirements 
Training  requirements 
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4.7.3  Conversion:   Batch  File  System  To  a  DBMS ._ 


Conversi  on   Experience 
Agency) . 


( a   Federa  1_   Government 


Goal s .   The  goals  of  this  agency  were: 

to  replace  outmoded  hardware 

to  implement  centralized   data   management   under   a 
•  data  base  administrator 
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to  implement  both  new  applications  and  redesigned 
systems  in  an  integrated  data  base,  on-line  disk  and 
telecommunications  environment,  under  a  data  base 
management  system,  in  order: 

to  permit  simple  query  capabilities 

to  treat  data  such  that: 

a.  input  multiple-use  data  only  once 

b.  have  it  accessible,  locally  and  from  distant 
cities,  by  terminal 

c.  allow  unstructured  queries  to  be  processed 
through  the  use  of  a  query  language  without  the 
necessity  for  programming 

Summary  of  actions.  As  a  Federal  agency,  the  options  were 
largely  "dictated  by  Federal  procurement regul ations  .  I f there 
were  no  regulatory  constraints,  the  alternatives  would  have 
been : 

to  determine  the  features  needed  by  the  data  base 
management  system,  evaluate  existing  DBMS's  and  buy 
a  computer  on  which  the  most  suitable  one  for  their 
needs  would  run. 

This  option  was  not  allowed  by  the  procurement 
regulations,  because  it  would  have  resulted  in  a 
sole  source  procurement. 

To  include  in  the  request  for  proposal  the  DBMS 
required  features.  This  option  was  not  allowed 
because,  in  their  case,  the  requirements  would  have 
unduly  restricted  competition. 


To  procure  the  hardware  under  open  competition, 
procure  the  software  separately. 


and 


However,  regulations  do  exist  and  the  ag 
select  the  final  option  which  the  procurement 
had  forced  upon  them. 

Cone! usions.    The   results,   in   terms   of   th 
creating   an    integrated   data   base   under 
management  system,  were   disastrous.    The   com 
that   was   procured  was  one  on  which  a  suitable 
exist.   After  two  and  a  half  years   of   effort 
through   established   DBMS   software  vendors,  a 
could  be  made  to  function  on  this  computer,   ei 
conversion   of   an   existing  DBMS  or  the  use  of 
development   software,   the   agency  has   not 
solution.   Even  after  a  contract  is  eventually 
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anticipate  a  12  to   18  month  wait   for  delivery  of  the 
product . 

Therefore,  it  is  safe  to  say  that  their  goal  of  moving 
onto  new  hardware  and  a  DBMS  has  been  so  delayed  by   Federal 
procurement  policy  that  it  will  take   3-1/2   to  4  years   for 
them  to  recover. 

Conversion  Experience  -  B   (a_   Federal   Government 
Agency) . 

Goal s.   To  convert  three   stand-alone   systems  with  the 
following  features: 

Input.  Batch  systems.  Inputs  manually  transcribed 
from  messages  onto  cards. 

.  Outputs.  Outputs  to  other  subsystems  in  the  form  of 
card  images  on  tape  that  was  hand  carried,  as  well 
as  printed  reports. 

The  features  of  the  new  system  were  to  be  as  follows: 

Inputs.  On-line  system.  All  error  corrections 
processed  and  corrected  interactively  on  a  CRT 
termi  nal  . 

Outputs.  Printed  reports. 

Ad   hoc   queries   available   through  a   DBMS   query 

1 anguage . 

Outputs  to  other  systems  automatically  generated  and 

forwarded  via  a  communications  network. 

Recommendati  ons . 

1.  Conversion  is  usually  a  one-for-one  affair. 
Redesign  occurs  when  the  requirements  are  changed. 
Conversion  is  usually  an  excuse  for  partial  or 
complete  redesign.  A  common  mistake  is  to  assume 
that  for  the  price  of  a  conversion  effort,  one  can 
also  redesign.  Experience  has  shown  that  this  is 
not  the  case.  Unrealistic  estimates  of  needed  time 
and  resources  result. 

2.  The  need  for  expertise  in  the  new  DBMS  is  greater  at 
the  beginning  of  a  project  than  at  any  other  time. 
Ironically,  this  is  the  time  before  your  staff  is 
retrained  and  when  your  expertise  level  is  the 
lowest.  Therefore,  outside  consultants  must  be 
brought  in.  These  outside  experts  will  have  a  great 
impact  on  your  data  base  design. 
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3.  The  DBMS  experts  will,  at  an  early  stage,  have  to 
design  the  data  base  structure.  The  system  design 
will  then  build  upon  this  data  base  structure.  The 
process  of  data  base  design  and  system  design  will 
be  iterative  with  a  series  of  changes  until  both  are 
in  sync. 

4.  The  extreme  pressure  to  get  off  old  machines  and 
operational  on  the  new  machines  prevents  sufficient 
time  for  thorough  analysis  and  planning.  And,  as 
discussed  above,  if  you  are  redesigning  and  not 
converting,  the  time  pressure  becomes  greater. 

5.  Government  procurement  regulations  do  not  recognize 
that  a  system  is  as  dependent  on  the  software  needed 
as  it  is  on  the  hardware. 

6.  The  move  from  separate  batch  systems  to  an  on-line 
integrated  system,  coupled  with  the  need  to  learn 
how  to  use  new  hardware,  require  careful  planning 
and  extensive  training  in  both  new  concepts  and  new 
techniques. 

7.  Moving  into  the  centrally  controlled  DBA  environment 
requires  lead  time  in  the  systems  development  cycle 
for  data  dictionary  development  and  implementation, 
and  for  data  standardization  to  be  done  carefully. 

8.  Time  required  to  accommodate  recommendations  five 
and  six  is  seldom  available  when  a  move  to  new 
hardware  is  underway.  The  result  is  hasty  and 
costly  straight  conversions  of  obsolete  systems; 
therefore,  the  potential  benefits  of  the  new 
hardware  are  delayed  or  lost. 

4.7.4  Conversion:   DBMS-1  To  DBMS-2. 


Conversion  Experi ence  -  A_. 
the   experience   of  moving  from 
change  in  vendors. 


This  conversion  illustrates 
one  DBMS  to  another,  with  a 


Goal s . 


To  provide  for  the  ability  to   update  concurrently 

and  retrieve  information  from  the  data  base. 

To  provide  for  a  quick   response   time  for   inquiry 
purposes . 
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To  provide  for  the  capability 
inquiry  even  if  the  DBMS  is  in 
recovery  stages. 


to   have   on-line 
abort  status  or  in 


To  provide  an  efficient 
the  data  base. 


way  to   recover   and   backup 


To  save  money  in  the  long  run. 

To  provide  tools  for  security  and  integrity   of  the 
DBMS. 


Summary  of  actions, 
considered: 


At  the  outset  several  alternatives  were 


Continue  with  the  present  DBMS.  This  alternative 
TmpTTed  maintaining  duplicate  data  bases--one  for 
inquiry  purposes  and  one  for  updating  purposes.  The 
inquiry  data  base  was  at  least  one  day  behind  the 
second  one  and  at  most  a  week  behind  the  latter.  In 
order  to  make  the  inquiry  data  base  as  current  as 
possible,  an  image  copy  was  made  once  each  week  of 
the  updated  base  and  copied  to  the  inquiry  data 
base . 


Update  the  DBMS  using  the  same  vendor. 
Convert  to 


another  DBMS 
"vendor 
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different   vendor. 
The new  vendor   agreed   to  convert  the  bulk 
system  quickly  and  with  the  least   amount   of 
changes  to  existing  modules.   This  vendor 
most  if  not  all  of  the  goals. 
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Upper  management  decided  to  convert  to 
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Using  the  initial  version  of  the  Emulator  would  have 
resulted  in  failure  to  maintain  the  necessary  production 
schedule.  A  task  force  was  brought  together  to  assess  the 
matter  and  determine  exactly  how  and  where  the  system  could 
be  improved.  The  task  force  included  site  staff  (three)  and 
vendor  staff  (two  persons). 

The  task  force  recommended  changing  some  Emulated 
programs  to  execute  under  standard  software  and  "looked  into 
the  Emulator  internals"  in  an  attempt  to  improve  some  of  its 
functions.  The  changes  yielded  significant  improvements; 
after  the  changes  were  effected,  the  regulator  production 
schedule  was  met. 


Another  significant 
not   perform   properly, 
mishandled.   On  the  rare 
this   sort  occurred,  the 
the  problem: 


problem  arose  when  the  Emulator  did 
e.g.,  a  call  to  the  data  base  was 
occasions  when  a  malfunction  of 
following  steps  were  taken  to  solve 


Disable  the  erroneous  call 

Inform  the  vendor  of  the  problem,  providing  complete 
documentation  on  the  problem 

Wait  for  the  solution 


Re-test  the  cal 1 

Re-load  the  new 
system  1 ibrary . 


version   of   the   Emulator   to   the 


The  prospect  of  losing  technical  support  for  the 
Emulator,  in  the  event  of  personnel  turnover  among  the 
vendor  staff  who  designed  and  developed  the  system,  was 
another  potential  problem.  This  situation  did  materialize, 
but  the  vendor  was  able  to  continue  technical  support  with 
other  individuals. 

Conversion  of  the  data  bases  themselves  went  extremely 
well.  Standard  utilities  were  used  to  unload  the  data 
bases.  The  tapes  were  moved  physically  to  the  new  vendor's 
facilities  and  were  converted  via  a  standard  vendor  utility. 
The  sub-files  were  loaded  employing  user  written  programs. 

Since  the  on-line  system  had  been  installed  on  the  new 
system  well  before  the  other  applications  systems,  there  was 
a  need  to  ensure  that  the  data  base  on  the  new  vendor  system 
was  as  current  as  the  old.  With  smaller  data  bases,  we 
unloaded  daily  from  the  old  vendor  and  loaded  daily  on  the 
new.  With  the  exception  of  our  largest  data  base,  the  other 
data  bases  were  unloaded  and  loaded  weekly  or   monthly.    To 
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keep  the  largest  sub-file  current  on  the  new  system,  we 
captured  the  data  base  changes  on  the  old  system  daily  and 
applied  them  to  the  new  data  base.  These  procedures  lasted 
for  approximately  one  year  until  our  other  applications 
systems  were  completely  converted. 

Cone! us  ions  .   To  summarize  our  findings: 

Differences  between  terminology  associated  with  each 
system  were  found  to  be  the  initial  barrier. 

Incremental  transition  was  recommended  as  a  means  of 
graduated  "phase-in"  to  the  new  DBMS. 

An  intermediate  software  system  was  procured  as  the 
method  of  transitioning  application  code.  DDL  and 
DML  functions  appeared  the  same  across  the 
transition.  Run-time  interpretation  of  code  through 
calls  to  interpretive-software  was  used  to  provide  a 
mapping  from  original  DBMS  to  native-made  DBMS 
calls.  Preliminary  conversion  of  DDL-type 
facilities  was  provided  at  compile  time  with  mapping 
structures  being  derived  for  use  at  interpretation 
time. 

Recommendations . 

1.  Experience  in  interpretation  and  run-time  mapping 
has  shown  that  system  overhead  can  be  prohibitive. 
Problems  encountered  in  execution  require  resolution 
by  the  developer  of  the  interpretive  software  and 
can  result  in  excessive  response  times.  It  is 
thereby  seen  to  be  more  practical  to  utilize 
standard  vendor  software  where  possible.  Conversion 
costs  may  be  higher  in  the  initial  investment  but 
will  eventually  be  equaled  and  even  surpassed  by  the 
overhead  costs  of  the  interpretive  method. 

2.  The  development  of  the  interpretive  software  was 
handled  by  the  vendor,  with  valuable  insight  of 
users.  User  involvement  in  the  implementation  of 
the  interpretive  software  provided  a  more  timely 
product  with  greater  response  to  requirements. 

3.  The  interpretive  software,  by  nature,  required 
processing  support  over  and  above  that  required  for 
actual  application  processing.  Direct  transition 
could  possibly  have  utilized  to  a  greater  degree  the 
processing  efficiency  of  the  target  DBMS.  Again, 
this  leads  to  the  realization  that  should  efficiency 
be  a  major  consideration,  direct  transition  may  be 
more  desirable. 
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In   util i  zing 
should    be 
methodol ogies 
descri  ption , 
transfer. 


direct   transition   methods,   vendors 

encouraged    to   develop   standard 

for   conversion   processes   in    data 

data   manipulation,   and   data   base 


Incremental  transition  insures  that  timely 
conversion  can  be  established  for  applications. 
Prototyping  efforts  are  provided  through  validation 
of  earlier  increments  of  the  entire  transition 
process . 

Fall  back  positions  must  be  established.  The 
transitioned  software  must  be  completely  validated 
before  actual  acceptance.  The  ability  must  always 
exist  to  turn-down  transitioned  software  due  to 
errors  without  degrading  overall  effectiveness  of 
the  data  processing  operations. 
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5.1   INTRODUCTION 

5.1.1  Objectives.  The  objective  of  the  Standards  Working 
p-aTel  we!  to  recommend  standards  that  a  manager  should 
consider  when  convertino  data  from  present  sources  (manual, 
semi-automated,  or  automated)  to  a  computer  Data  Base 
Management  System  (DBMS  as  it  is  commonly  known).  The  Panel 
considered  administrative  guidelines  as  well  as  technical 
standards  since  both  are  essential  to  an  effective 
conver si  on  process  . 
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5.1.2  What  Is  a  Standard?  A  "Standard"  is  a  consensus  or 
common  practice  sometimes  established  by  authority  derived 
from  a  desire  to  reduce  arbitrary  variety  for  economic 
reasons.  A  standard  is  one  method  of  insuring  compatibility 
by  using  accepted  conventions. 
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In  the  case  of  FIPS,  ANSI,  end  ISO,  a  formal   mechanism 


has   been   established   to   propose,   review, 

validate  standards.    While   A MSI   and   ISO 
voluntary   for   all   participants,   the   FIPS 

mandatory  within   the   Federal   Government, 
standards   to   be   effective,   an  enforcement 

mechanism  is  necessary. 


approve .  and 
standards  are 

standards  are 
For  mandatory 
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5.1.3  Background.  As  yet,  no  formal   DBMS   standards   exist. 
Many   groups    concerned   about  standardization  are    actively 

The  committee  felt  that  a   review  of 

be  worthwhile  for  the 
Data   Ba  se 


working  in  this  area  .      .  .  ,  ,  , 

the  various  Standards  activities  would 
reader.  The  Committee  included  in  its  review  the  . 
Directions  I  Report  and  the  activities  being  carried  on  by 
voluntary  groups;  specifically,  the  ANSI /X 3 /SPARC  and 
CODASYL  groups. 
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governmental  operating   bodies,   such   as   Congressman   Jack 
Brooks   and   the   House   Operations   Committee  in  the  United 


States,  European  Economic   Community 
effect,   no   firm   standards   efforts 
[Editors's  note:   subsequent   to   the 
report  but  prior  to  publication.  ANSI 
activities.] 
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Many  practical  data  base  conversions  have  been 
undertaken  successfully  --  both  from  conventional  systems 
to  a  computer  data  base  system,  or  from  one  computer  data 
base  system  to  another  computer  database  system.  A  body  of 
evidence  indicating  the  economic  superiority  for  the  data 
base  approach  is  accruing.  The  reader  will  read  of  such 
evidence  in  other  sections  of  this  report. 

American  National  Standards  Institute  (ANSI)  .  The 
Standards  Planning  and  Requirements  Committee  (SPARC.)  of 
ANSI/X3  (Computers' and  Information  Processing)  established 
in  1972  a  study  group  which  was  chartered  to  investigate  the 
potential  for  standardization  in  the  area  of  DBMS. 

During  early  deliberations,  the  study  group  concluded 
that  the  proper  subjects  for  DBMS  standardization  were 
interfaces  within  a  DBMS.  It  was  then  necessary  to  define  a 
framework  for  DBMS.  In  1975,  the  study  group  produced  an 
interim  report  [3]  which  described  such  a  framework.  A 
revised  report  has  also  been  published  recently  [4]  which 
represents  the  study  group's  most  important  ideas  relevant 
to  standardization. 
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Although  the  study  group  itself  did   not  recommend   to 

its    parent,    ANS I /X3/SPARC  ,   action    for  or   against 
standardization  of  any  DBMS  component,  SPARC  recommended   to 

ANSI/X3  that  standardization  efforts  begin  on  a  CODASYL  Data 

Definition   Language   (DDL)   and   on   CODASYL  additions   to 

FORTRAN   end   COBOL   for   data   manipulation  (DML).    These 
efforts  have  been  initiated. 
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5.2   POTENTIAL  BENEFITS  THROUGH  STANDARDIZATION 

Standardization  can  provide  many  benefits  to  vendors 
and  users  involved  in  conversion  tasks.  In  this  sense, 
users  mean  the  applications  development  people  who  will 
actually  perform  the  conversion.  The  benefits  can  take  many 
forms.  Among  the  benefits  the  committee  felt  could  be 
realized  were: 


Improved  Portability.  Defining  in  a  standard  way 
the  logical  relationships  of  data  would  in 
particular  insure  that  diverse  hardware  and/or 
software  implementations  could  successfully  address 
the  same  logical  data.  This  could  minimize  hardware 
dependencies  and  allow  the  users  to  progress  to  both 
different  and  improved  technology  with  a  minimum 
expenditure  of  both  time  and  money.  Portability 
would  provide  protection  against  loss  of  the  usually 
sizeable  investment  required  by  the  user  to 
establish  a  data  base. 


Improved  Education.  Standards  could  provide  a  basis 
upon  which  educational  institutions/corporations  can 
structure  their  data  processing  training  programs  to 
satisfy  the  needs  of  their  personnel.  In  effect, 
standards  could  reduce  the  time  and  expense  of 
retraining  data  processing  staffs. 

Enhanced    Communication.    Standard  terms    and 

definitions   would  enhance  communication  among  users 

and/or  vendors.   As  it  now  stands,  these  terms   are 

being  haphazardly  developed  and  becoming  widely  used 
with  little  common  understanding. 

Product  Specification.  Standards  would  provide 
product  specifications  that  could  be  met  by  all 
vendors.  End  users  will  have,  therefore,  more 
precise  product  specifications  and  could  exercise 
greater  impact  on  what  products  would  be 
manufactured  to  satisfy  their  needs. 

Easier  to  Specify  User  Requirements.  The 
standardization  machinery  would  enable  the  user 
community  to  be  involved  in  the  evolution  of  the 
data  base  technology.  In  this  respect,  it  should  be 
self-evident  that  the  user  would  have  a  far  greater 
interest  than  the  vendor  in  ensuring  that  the 
standards  applicable  to  data  base  reflect  the  need 
to  minimize  the  problem  of  conversion. 


N 
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5.3   SOFTWARE  COMPONENTS  IN  CONVERSION  PROCESS 


Th 
data  b 
standar 
four  d 
which  , 
conver s 
standar 
environ 
many  pa 
a  v  a  i  1  a  b 
less  co 
many  i 
s  u  b  s  t  i  t 
s  i  t  u  a  t  i 
c  hanae 


is  s  e  c  t  i  o 
a  s  e   e  n  v  i 
d  i  z  e  d  .   T 
i  f  f  e  r  e  n  t 
if  s t a n d a 
ion.    In 
d  has  not 
m e n t "  is 
r  t  s  m  a  k  i  n 
le  for  sh 
nfusing  t 
n  s  t  a  1 1  a  t  i 
ute   for 
on ,   the 
of  access 


n  exam 
ronmen 
he  rat 

con  ve 
r  d  i  z  e  d 
all 
been 
used  t 
g  up  a 
ared  u 
han  us 
ons   a 

t  r  a  d  i 
e  n  v  i  r  o 

metho 


ines  the  software  components  of  the 
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ionale  for  standardization  is  based  on 
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cases,  technical  feasibility  of  the 
considered.  The  term  "data  base 
o  describe  an  environment  in  which  the 
n  organization's  data  base  would  be 
se  and  coordination.  This  approach  is 
inq  the  term  "DBMS  environment,"  since 
re  merely  using  the  DBMS  software  as  a 
tional  access  methods.  In  this 
nment  has  not  changed;  it  is  merely  a 
d. 


The  term  DBMS  will  be  used  to  describe  the  software 
used  to  manipulate  the  computer  resident  portion  of  the  data 
base.   The  conversion  scenarios  considered  were: 


Moving   from   a   non-data   base   environment   to   a 
data  base  environment  using  a  standard  DBMS. 

.   Moving  from  a  standard  DBMS   to   the   same   standard 
DBMS  within  a  different  hardware  environment. 

.   Moving  from  a  Type  A  standard  DBMS   to   a   different 
Type  B  standard  DBMS. 

.   Moving  from  a  standard  DBMS  to  a   non-standard   DBMS 
environment. 


5.3.1  Scenario  1 


Moving  from  the  non-data  base  environment 
to  the  standard  data  base  environment.  When  considering  the 
processes  involved  in  data  base  conversion,   several   points 


several 
can   be    identified   which   can   be   facilitated 
availability  of  standard  tools  or  methods. 


by   the 


Data  Fl ow  Analysis .  To  determine  the  organization  s 
data  FeouTriments ,  a  data  flow  analysis  should  be 
undertaken.  To  facilitate  this  analysis  a  standard  approach 
is  needed.  It  should  include  a  complete  description  of  the 
data  and  where  it  is  used,  including  all  input  and  output 
documents,   both  manual  and  automated  processes. 

Dictionary/directory  System  (D/DS_).  Although  it  may  be 
premature  to  consider  a  standard  for  a  D/DS,  this  is  an 
important  tool  for  definition  analysis  and  data  flow 
analysis   and   to   facilitate  access  to  this  information.   A 
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more  detailed  discussion  of   the   possible 
presented  elsewhere  in  the  report. 


capabilities   is 


Data  Management  Function.  An  organizational  group 
concerned  with  overall  responsibility  for  the  management  of 
data,  both  computerized  and  non-computerized.  This  function 
should  have  a  specific  functional  description. 

Data  Base  Administrator.  A  position  holding  primary 
responsibility  for  the  overall  accuracy,  timeliness,  and 
availability  of  the  corporate  data  through  direct  control 
over  the  data  dictionary/directory  system.  This  position 
located  within  the  data  management  function  should  have 
clearly  understood  responsibilities. 

Loading  the  Computer   Data   Base.    To 
conversion   effort,   specific   conventions 
piecing  date  into  data  bases  initially. 


faci 1 i tate   the 

are   needed   for 


Conversion  To  the  Data  Base  Envi  ronment  This  can  be 
accomplished  by  either  "Til  moving  current  applications  to 
the  new  environment  with  no  major  changes  in  process  or  (2) 
creating  new  applications.  Both  approaches  use  a  Data 
Manipulation  Language  (  D  M  L  )  to  access  the  data  base  from  a 
user-oriented  view  of  the  database. 


5.3.2  Scenerio  2 


I  DBMS 
the  same  standard  and 


to  DBMS  conversion  where  each  DBMS 
is  tne  same  standard  a  no  only  the  hardware  changes.  In  this 
case,  the  steps  in  scenario  1  were  presumably  implemented 
already.    However,  additional  problems  occur: 


Data  Translation .  Moving  the  data  in  the  source 
computer  data  baTe  to  the  target  computer  data  base.  This 
reouires  a  translation  of  the  data  from,  physical  structure 
of  the  source  computer  to  the  physical  structure  of  the 
target  computer.  A  needed  standard  facility  would  be  a 
method  of  unloading  the  physical  data  to  a  standard 
interchange  format,  in  display  format  representation,  and 
then  loading  that  data  into  physical  structure  of  the  target 
computer . 

Program  Transl at  ion .  Restatement  of  the  application 
programs  reflecting  changes  to  the  description  of  data  are 
necessary  as  well  as  changes  to  the  application  programs. 
Standard  data  description  and  date  menipulation  functions 
are  needed  in  addition  to  those  stated  in  scenario  1. 
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5.3.3  Seen a r i o  3 
different 


Conversion  between  standard  versions  of 
DBMS.  Assumes  both  standard  DBMS  incorporated  the 
points  in  scenario  1.  No  additional  points  beyond  those 
described  above  are  needed,  but  significant  differences  in 
the  details  of  the  data  models  may  occur. 

5.3.4  Scenario  4.  Standard  DBMS  to  non-standard  DBMS 
conversion.  Similar  to  Scenario  3  because  there  would  be  no 
reason  to  make  this  step  unless  no  standard  DBMS  satisfies 
information  requirements. 

5.3.5  Miscellaneous  Standards  Necessary.  Additional  computer 
components  considered  and  mentioned  as  desirable,  but  for 
which  standards  may  be  premature  or  which  may  not  affect  the 
conversion  effort  are: 

.  Standard  end-user  facilities;  i.e.,  a  means  whereby 
a  non-computer  professional  can  communicate  with  the 
data  base. 


Network  interfaces. 

Restart  f unc ti  ons . 

Security  functions. 

Communication  facilities. 

Command  Languages  (operating  systems). 

5.3.6  Non-software  Components  Necessary.  Many  non-software 
components  are  involved  in  any  conversion  process.  Those 
considered  by  the  committee  include: 


Admi  ni  strati ve/management   Procedures. 

which" 


The  committee 


identified  no  Ttandards  which  could  be  applied  to  these 
procedures  during  conversion.  However,  the  development  of 
guidelines  and  "checklists  based  on  earlier  experience  and 
lessons  learned  would  be  \/ery    useful. 


Standards . 


The 


Veri  fi cat  ion   of   Com pi iance   With 

committee  believed  there  is  a  need  for  a  standard  approach 
to  validating  compliance  with  DBMS  standards.  An  important 
component  of  such  a  validation  would  be  having  a  set  of 
common  procedures  for  measuring  compliance. 
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5.4   RECOMMENDATIONS 

Two  areas  should  be  considered  immediately  for 
standardization  if  progress  toward  successful  conversions  is 
to  be  made.   These  two  areas  are: 

Development  of  a  standard  DBMS. 

Development  of   a   Generalized   Dictionary/Directory 
System. 

5.4.1  The  Development  of  a  Standard  DBMS.  A  DBMS  standard 
would  benefit  government  and  industry  in  their  conversion 
efforts  and  the  Committee  encourages  progress  toward  a  DBMS 
standard.  The  work  of  CODASYL  group,  with  some  possible 
modifications,  appears  to  offer  a  first  step  toward  the 
complete  specification  of  a  DBMS,  although  some  committee 
members  felt  several  sucessful  commercial  DBMS  may  become  de 
facto  standards.  The  committee  also  believed  that 
consideration  should  be  given  to  the  idea  that  the  standard 
should  not  inhibit  any  future  technological  developments  in 
hardware  and  software. 

5.4.2  Generalized  Dictionary/directory  System.  The  use  of  a 
D  i  c  t  i  o  n  a  ry / D  i  r  e  c  to  ry  facility  is  highly  desirable  as  a  tool 
in  any  conversion  process,  whether  from  manual  or 
conventional  file  to  a  data  base  environment  or  from  one 
DBMS  to  another  DBMS.  The  advantages  for  the  use  of  a 
dictionary  facility  will  be  gained  primarily  in  the 
followino  two  areas: 


It  will  allow  the  proper  assessment  and  definition 
of  the  organization's  data  to  be  undertaken  or  to  be 
made  prior  to  the  start  of  a  project. 

It  provides  an  essential  management  mechanism  to 
control  the  actual  development  of  the  new  system. 

Since,  in  this  sense,  the  dictionary  facility 
chronologically  precedes  the  DBMS  targeted  in  the 
conversion,  it  appears  likely  that  the  direct  support  of  the 
dictionary  facility  itself  should  not  depend  on  the  target 
DBMS,  or,  for  that  matter,  on  any  particular  DBMS.  In  any 
case,  the  dictionary  facility  must  be  able  to  support 
descriptive  facilities  for  the  data  in  a  logical  mode. 

Another  useful  capability  is  that  of  being  able  to 
produce  processable  data  descriptions  in  the  target  DBMS 
environment.  This  does  not,  however,  imply  that  this  target 
DBMS  must  be  used  in  the  implementation  of  the  dictionary 
facility,  but   rather   that   a   suitable   (possibly   manual) 
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interface  to  this  DBMS  be  made  available.  It  would  be 
highly  desirable,  if  not  required,  that  all  DBMS  had  the 
same  logical  interface.  Then  the  dictionary  could  interface 
with  multiple  DBMS  at  the  same   time. 

In  discussing  the  architectural  placement  of  the 
dictionary,  this  facility  should  not  exist  as  an  adjunct  to 
any  DBMS,  but  as  a  separate  facility  that  interfaces  to  data 
in  conventional  files  as  well  as  to  data  being  managed  by 
one  or  more  DMBS.  A  distinction  needs  to  be  made  in  the 
manner  in  which  the  dictionary  facility  is  invoked; 

In  the  case  of  a  free-standing  dictionary,  this 
facility  is  invoked  under  user  control.  As  such,  it 
is  a  user  option  if,  and  when,  the  dictionary  is  to 
be  invoked  in  the  execution  of  any  process. 

In  the  case  of  an  integrated  dictionary,  which  means 
the  data  dictionary  is  directly  available  to  the 
DBMS,  this  facility  might  be  invoked  automatically 
by  the  system  itself  in  the  execution  of  any 
process,  thus  assuring  synchronization  of  the 
process  with  the  information  contained  in  the 
dictionary.  The  feasibility  of  this  approach 
depends  on  the  overhead  burden  it  may  generate. 

Since  the  use  of  some  of  the  currently  available 
dictionary  facilities  is  believed  to  be  of  considerable 
value  in  the  attainment  of  these  and  other  goals,  it  is 
visualized  that  a  more  general  facility,  called  a 
Generalized  Dictionary/Directory  System,  would  be  more 
effective.  In  brief,  a  GD/DS  is  an  information  system  in 
and  of  itself  whose  subject  matter  is  all  the  information 
about  the  enterprise  on  the  following  classes  of  entities: 

Data  Components  . 

Processing  Components. 

People  and  Organizational  Components. 

Events  . 

Attributes  to  be  included  in  the  data  dictionary  ere 
those  about  the  entities  themselves,  the  relationship  that 
exists  among  the  entities,  as  well  as  the  context  in  which 
these  relationships  exist.  For  example,  among  the 
attributes  would  be  the  relationship  between  systems  and 
both  automated  and  manual  procedures.  The  generalized  data 
dictionary/directory  should  contain  not  only  the  logical 
attributes  and  relationships  between  the  entitites 
described,  but  also  attributes  associated  with  the   physical 
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location  of  the  entities 


5.5   CONCLUSION 


In  summary,  the  committee  strongly  believes  that  many 
areas  for  standardization  exist  within  the  conversion 
process  and  the  data  base  environment  in  general.  The 
committee  notes  with  frustration  the  lack  of  overall 
progress  since  the  first  Data  Base  Directions  workshop. 
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The  committee  observed  that  the  installation  process 
actually  should  be  reversed  with  the  data  dictionary 
introduced  first.  All  of  the  data  within  the  environment 
and  the  systems  that  use  them  should  be  carefully  documented 
end  defined  (including  all  the  developmental  shortcuts  that 
had  been  taken  in  the  past),  and  then  entered  into  a 
Generalized  Dictionary/Directory.  Once  this  is 
accomplished,  then  the  appropriate  data  bases  to  support 
their  various  information  systems  in  the  organization  can  be 
built. 
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6.1   INTRODUCTION 


6.1.1  The  Scope  of  the  Conversion  Problem.  Two  factors  make 
conversion  necessary:  changes  i  n  users'  functional 
requirements  and  changes  in  their  performance  requirements. 
These  changes  may  necessitate  the  acquisition  of  new 
software  and  hardware  which,  in  turn,  may  require  changes  to 
the  existing  data  programs.  For  example,  the  acquisition  of 
a  data  base  management  system  to  replace  a  file  management 
system  requires  the  integration  of  the  original  files  into  a 
data   base   system  and  modification   of  the   programs  to 

replacement  of  a  current  DBMS  with  a 

provide  additional  functionality  may 

way  of  logically  structuring  the 

model)   and   a  different   kind   of 

The   establishment  of  a  communication 


interact  with  it.   The 
new  data  base  system  to 
require   a   different 
information   (its   data 
1 anguage   i  nterface . 


network  between  differing  systems  to  implement  data  sharing 
will  require  dynamic  (i.e.,  in  real  time)  conversion  of  data 
between  different  nodes  in  the  sense  that  the  same  item  will 
repeatedly  undergo  conversion  as  it  is  needed,  or 
alternatively,  it  requires  conversion  of  programs  when  they 
travel  to  different  nodes  to  access  data  there.  Even  when 
the  acquisition  of  new  software  or  hardware  is  not 
warranted,  changes  in  a  users'  functional  and  performance 
requirements  can  require  data  and  program  conversion. 

What  makes  conversion  difficult  is  the  proliferation  of 
data  models  and  levels  and  styles  of  DBMS  interfaces, 
internal  data  representation,  and  hardware  architecture. 
This  panel  will  examine  the  technology  that  has  been 
developed  to  perform  conversions,  analyze  the  areas  which 
require  new  or  improved  techniques,  and  consider  strategies 
for  minimizing  the  need  to  convert  as  well  as  for 
streamlining  the  unavoidable  conversions.  Over  the  past  six 
years,  research  and  development  has  primarily  centered  on 
the  problem  of  converting  in  non-dynamic  environments.  The 
first  part  of  the  section  called  "CONVERSION  TECHNOLOGY" 
surveys  tools  and  technology  currently  available  for  the 
conversion  of  data  organization.  More  recently,  data  base 
program  conversi on--probabl y  the  most  difficult  part  of  the 
conversion  problem--has  received  attention.  The  middle  part 
of  this  section  considers  the  directions  being  taken  by 
current  data  base  conversion  research.  The  final  part 
analyzes  the  status  of  the  entire  technology.  The  third  and 
final  section  explores  the  factors  affecting  conversion,  the 
approaches  for  reducing  the  need  to  convert  data  and 
applications  programs,  and  the  impact  of  new  software  and 
hardware  technologies  on  conversion.  Section  4  summarizes 
the  trends  in  conversion  needs  and  tools. 
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6.1.2  Components  o f  the  Conversion  Proces 
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Fi  gure  6-1 
A  Data  Conversion  Model 
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Concepts  of  Data  Conversion 


In  brief  and  conceptual  terms,  the  data  translation  or 
conversion  process  can  be  represented  di agrammatical  1  y  in 
Figure  6-1.  As  shown  in  this  diagram,  a  data  translation 
system  generally  requires  three  components:  a  reader,  a 
restructurer ,  and  a  writer.  While  the  capability  of  each 
component  depends  on  the  individual  design  of  a  data 
translation  system,  the  reader,  in  general,  accesses  data 
from  its  source  environment  to  prepare  it  for  further 
processing.  The  accomplishment  of 
unquestionably  requires  a  description  of  the 
a  data  description  language.  The  writer  is 
inverse  of  the  reader, and  puts  the  transformed  data  into  the 
target  environment.  It  too  requires  a  description  of  the 
data  structure  and  shares  with  the  reader  the  need  of  a  data 
description  language.  The  restructurer  functions  quite 
differently  from  that  of  the  other  two  components.  This 
component,  in  general,  extracts  data  from  its  source  or 
internal  forms  and  restructures  it  to  a  desired  format  or 
structure.  This  process  usually  requires  a  translation 
description  language. 
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as  those  used  to  drive  the  data  translation  process.  The 
program,  the  description  of  its  semantics,  and  the 
description  of  the  data  conversion  are  inputs  to  the  program 
conversion  process.  It  uses  them  to  determine  the  data 
originally  accessed  and  how  to  accomplish  the  same  access  in 
the  new  structure,  and  it  produces  a  new  program  to  do  this. 
Currently,  a  combination  of  manual  translation,  emulation, 
and  bridge  programs  accomplishes  this  conversion  process  and 
an  automatic  or  semi-automatic  program  conversion  technology 
is  only  in  the  early  stages  of  research. 
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Figure  6-2 
Program  Translation 


6.2   CONVERSION  TECHNOLOGY 

This  section  turns  from  the  general  concepts  of  data 
and  program  conversion  to  the  technology  by  which  a 
conversion  is  achieved.  Since  most  of  the  conversion 
results  have  been  achieved  in  data  conversion,  we  focus  on 
this  aspect  and  limit  our  discussion  on  program  conversion 
to  those  cases  which  are  the  result  of  a  data  conversion. 
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.6.2.1  Data  Conversion  Technology 


Currentl y  ,  a  s   t 
approach   to   data conversion,   one  develops 
programs  for  each  transfer  of  data  from  one   envir 
another.    This   approach   is   inherently  expens 
programs   are   developed   for   use   only  once   a 
development   costs   cannot   be   amortized.    Furt 
reliability  results  from  the  greater   likelihood 
errors   as   data   is   passed  from  program  to  progr 
large  data  conversion   effort,   tracing   data   bac 
several   passes  to   the  source  of  an  error  in  the 
particular  point  can  become  unmanageable.   As  an  a 
one  may  search   for  a  broader  approach  to  data 
with  a  generalized   system.    We   shall   now  desc 
systems  in  more  detail. 
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Probl em  Discussion.  Data  exists  in  many  varied  and 
complex  forms;  Figure  6-3  (next  page),  an  expanded  form  of 
the  diagram  in  Figure  6-1,  indicates  some  of  the 
transformations  that  need  to  take  place  in  a  data 
conversion.  This  diagram  illustrates  the  capabilities 
needed  by  the  read  and  write  process  in  a  data  conversion 
system. 

Unloading  of  data  from  its  source  permits  reducing  the 
complex  physical  structure  of  the  source  data  base  to  a  very 
simple  physical  structure;  namely,  a  sequential  data  stream. 
The  source  data  base  contains  not  only  the  information  that 
interests  the  user,  but  also  a  large  amount  of  control 
information  specific  to  a  particular  system.  This  control 
information  is  used  by  the  system  for  such  data  management 
functions  as  overflow  chaining,  index  maintenance,  and 
record  blocking.  For  example,  many  systems  mark  a  record 
to  be  deleted  rather  than  actually  delete  it  and  the  unload 
transformation  can  remove  such  system  specific  information. 
Another  factor  that  causes  complexity  in  the  unloading 
process  is  the  frequent  use  of  pointers  in  a  source  system. 
Pointers  are  used  for  two  basic  purposes:  (1)  to  represent 
relationships  that  exist  between  record  instances,  and  (2) 
to  implement  alternative  access  paths  to  the  data.  During 
the  unload  transformation,  the  second  class  of  pointers  may 
be  discarded  without  loss  of  information.  The  first  class 
of  pointers,  however,  contains  information  that  the 
transformation  must  preserve. 

The  reformat  process  creates  a  common  data  form  of  the 
source  data  for  the  restructuring  step  in  the  conversion 
process.  In  the  case  of  a  simple  sequential  file,  not  under 
DBMS  control,  it  may  enter  the  conversion  process  at  this 
point.  Depending  on  the  design  of  a  system,  this  step  may 
involve  editing  (i.e.,  encoding  or  recoding  of  items), 
limited  data  extraction,  correction,  and  the  like. 


-110- 


(/) 
t/> 
ttJ 
u 
o 
s- 

O. 

c 
o 

•r- 

ro   to 

I      S- 
tO    CD 

> 

QJ  C 
J-  o 
3  (_> 

•r-    rtj 

Li-    -P 

(T3 

O 


+-> 


O) 


o 


-111- 


Since  this  step  seeks  to  create  a  data  structure  of  the 
source  data  without  system-dependent  information,  one  can 
consider  the  mapping  between  the  input  and  the  output  of  the 
reformat  process  to  be  generally  one-to-one.  While  this 
step  looks  simple  functionally,  its  actual  application  and 
implementation  can  be  quite  complex.  For  example,  an 
application  program  may  use  the  high  order  bits  of  a  zoned 
decimal  number  for  its  own  purposes,  knowing  that  these  bits 
are  not  used  by  the  system.  Such  specifications  of 
nonstandard  item  encodings  present  a  difficult  problem  in 
data  conversion. 


of  the   unload 
Note,  however, 
that  the  use  of   a   common   data   form   provides   additional 
benefits,  such  as  easing  the  portability  problem. 


The  load  process   is   the   counterpart 
process   and  needs  no  further  clarification. 


The  restructuring  process  undoubtedly  represents  the 
most  complex  process  of  a  generalized  data  conversion 
system.  The  languages  for  this  mapping  process  can  differ 
widely  (for  example,  some  procedural  and  other 
nonprocedural)  and  the  models  used  to  represent  the  data  in 
the  conversion  system  are  also  quite  divergent.  (For 
example,  some  use  network  structures;  others  use 
hierarchical  structures).  More  will  be  said  on  this  topic 
later  in  this  section. 

Let  us  now  turn  to  discuss  the  issue  of  implementation 
briefly.  Generally,  there  are  two  techniques:  an 
interpretive  approach  or  the  generative  approach.  In  the 
interpretive  approach,  the  action  of  the  system  will  be 
driven  by  the  descriptions  written  in  the  system's  languages 
via  the  general  interpreter  implemented  for  the  particular 
system.  In  the  generative  approach,  the  data  and  mapping 
descriptions  are  fed  into  the  compiler(s)  which  generates  a 
set  of  customized  programs  executable  on  a  certain  machine. 
Later  in  this  section  we'll  discuss  the  merits  of  each  of 
these  approaches. 

Turning  our  attention  to  the  tools  that  have  been 
developed  for  data  conversion,  we  shall  first  discuss 
currently  available  tools  and  then  the  research  and 
development  work  in  progress. 

Available  Conversion  Tools.  Currently,  available  tools 
have  limited  capabilities.  Because  it  is  impossible  in  this 
short  report  to  provide  an  exhaustive  survey  of  all  the 
vendor-developed  conversion  tools,  we  will  highlight  the 
spectrum  of  capabilities  available  to  the  user  by  providing 
examples  from  specific  vendor  shops. 
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The  repertoire  of  vendor  conversion  tools  begins  at  the 
character  encoding  level  of  data  conversion  with  the 
provision  of  hardware/firmware  options  and  continues  through 
the  software  aids  for  conversion  and  restructuring  of  data 
bases. 
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Some  data  base  restructuring  tools  specific  to  a 
particular  DBMS  have  been  developed  by  DBMS  users.  One 
example  of  this  type  of  tool  is  RE0RG  [Rll],  a  system 
developed  at  Bell  Laboratories  for  reorganization  of  UNIVAC 
DMS-1100  data  bases.  RE0RG  provides  capabilities  for 
logical  and  physical  reorganization  of  a  data  base  using  a 
set  of  commands  independent  of  DMS-1100  data  management 
commands.  A  similar  capability  has  been  developed  at  the 
Allstate  Insurance  Company. 
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In  addition  to  the  above,  there  are  also  software 
companies  and  vendors  who  will  do  a  customized  conversion 
task  on  a  contractual  basis. 


Data  Conversion  Prototypes  and  Model s .  Over  the  past 
seven  years,  a  greaT  deal  of  research  on  the  conversion 
problem  has  been  performed,  with  the  results  summarized  in 
Figure  6-4.  The  University  of  Michigan,  the  University  of 
Pennsylvania,  IBM,  SDC ,  and  Bell  Laboratories  initiated 
projects,  as  well  as  a  task  group  of  the  CODASYL  Systems 
Committee.  In  many  cases,  interaction  and  cross- 
fertilization  between  these  groups  led  to  some  consensus  on 
appropriate  architectures  for  data  conversion.  The 
individual  achievements  of  these  groups  is  discussed  below: 
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The  Un  i  versi  ty  of  Mi  chi  gan .  The  nonprocedural  approach 
to  stored-data  definition  set  forth  by  Taylor  and  Sibley 
[SL3,6]  provided  one  of  the  major  foundations  for  the 
development  at  the  University  of  Michigan  (see  Figure  6-4) 
of  data  translators.  In  concert  with  Taylor's  language, 
Fry,  et  al.  [DTI]  initiated  a  model  and  design  for  a 
generalized  translation. 


The   translation   model   was 
implementation   of   the   Michigan 


tested   in   a    prototype 
Data   Translator   in  1972 


[UT2,4],  and  the  results  of  the  next  implementation,  Version 
I,  were  reported  by  Merten  and  Fry  [DT4]. 

In  1974,  the  work  of  the  Data  Translation  Project  of 
the  University  of  Michigan  focused  on  the  data  base 
restructuring  problem.  Navathe  and  Fry  investigated  the 
hierarchical  restructuring  problem  by  developing  several 
levels  of  abstractions,  ranging  from  basic  restructuring 
types  to  low  level  operations  [R6]. 
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Fi  gure   6-4 
Historic    Context    of    Data    Conversion    Efforts 
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Figure   6-4    (continued) 
Historic    Context   of   Data    Conversion    Efforts 
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Later,  Navathe  proposed  a  methodology  to  accomplish 
operations  using  a  relational  normal  form  for  the  int 
representation  [DT12].  Version  II  of  the  Michigan 
Translator  was  designed  to  perform  hierarc 
restructuring  transformations,  but  the  project  did 
implement  it.  Instead,  the  research  was  directed  int 
complex  problem  of  restructuring  network  type  data  b 
To  address  this  problem,  Deppe  developed  a  dynamic 
model--the  Relational  Interface  model--which  simultane 
allowed  a  relational  and  network  view  of  the  data 
[UR3].  This  model  formed  the  basis  of  the  Version 
design  and  implementation  of  generalized  restruct 
capabilities  [UT8,9,10].  Another  component  necessary 
the  development  of  a  restructurer  was  the  formulation 
language  in  which  to  express  the  source  to  target 
transformations.  This  language,  termed  Transl 
Definition  Language  (TDL),  evolved  through  each  trans 
version  beginning  with  a  source-to-target  data  item  "e 
list"  in  the  Version  I  Translator  to  the  ne 
restructuring  specifications  of  Version  IIA.  Whil 
initial  version  of  the  TDL  was  quite  simplistic,  the  cu 
version,  the  Access  Path  Specification  Language  [DT16 
provides  powerful  capabilities  for  transforming  network 
bases . 
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IBM  Research,  San  Jose  In  1973,  another  major  data 
translation  research  endeavor  was  initiated  at  the  IBM 
Research  Laboratory  in  San  Jose,  California.  Researchers  in 
this  project  —  initially  Housel  ,  Lum,  and  Shu,  later  joined 
py  bhosh  and  Tayl or— adopted  the  general  model  as  specified 
in  Figure  6-1  but  made  several  innovations.  First,  in  the 
belief  that  programmers  know  well  the  structure  of  the  data 
in  a  buffer  being  passed  from  a  DBMS  to  the  application 
program,  the  group  concentrated  its  effort   on  designing   a 
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data  description  language  appropriate  for  describing  data  at 
this  stage.  Second,  regardless  of  the  data  model  underlying 
any  DBMS,  the  data  structure  at  the  time  it  appears  in  the 
buffer  of  an  application  program  will  be  hierarchical.  The 
general  architecture,  methodology,  and  languages  reflecting 
these  beliefs  is  reported  in  Lum  et  al.[DT14]. 

In  addition,  the  group  in  San  Jose  felt  that,  while  it 
is  desirable  to  have  a  file  with  homogeneous  record  types, 
it  is  a  fact  of  life  that  many  of  today's  data  are  still  in 
COBOL  files  in  which  multiple  record  types  frequently  exist 
within  the  same  file.  As  a  result,  the  group  concentrated 
on  designing  a  data  description  language  which  can  describe 
not  only  hierarchical  records  (in  which  a  relational 
structure  is  a  special  case)  but  also  most  of  the  commonly 
used  sequential  file  structures.  This  language,  DEFINE,  is 
described  by  Housel  et  al-[SL7]. 

The  philosophy  of  restructuring  hierarchies  is  further 
reflected  in  the  development  of  the  translation  definition 
language  CONVERT,  as  reported  by  Shu  et  al  [R2].  This 
language,  algebraic  in  structure,  consists  of  a  dozen 
operators,  each  of  which  restructures  one  or  more 
hierarchical  files  into  another  file.  The  language 
possesses  the  capability  of  selecting  records  and  record 
components,  combining  data  from  different  files,  built-in 
functions  (e.g.,  SUM  and  COUNT),  and  the  ability  to  create 
fields  and  vary  selection  of  the  basis  of  a  record's  content 
( a  CASE  statement) . 

A  symmetric  process  occurs  at  the  output  end  of  the 
translation  system.  Sequential  files  are  created  to  match 
the  need  of  the  target  loading  facility.  The  specification 
of  this  structure  is  again  made  in  DEFINE. 


A  prototype  implementation,  originally 
but  renamed  XPRS,  is  reported  in  [DT15]. 
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Two  processing  paths  are   available   within   the   ADAPT 
system:   a  file  translation  path  and  a  data  base  translation 
path  (see  Figure  6-3).   A  separate  path  for 
responds   to   real-world   considerations: 
conversions  do  not  require  the  capabilities 
high   overhead   involved   in   using   a  data 
path  . 


file  translation 
many  types  of 
and   associated 

base  translation 


Rel ated  Work  Additional  research  effort  examines  the 
development  and  acceptance  of  a  standard  interchange  form. 
An  interchange  form  would  increase  the  sharing  of  data  bases 
and  provide  a  basis  for  development  of  generalized  data 
translators.    The   Energy   Research   and    Development 
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Administration  (ERDA)  has  been  supporting  the 
Interl aboratory  Working  Group  for  Data  Exchange  (IWGDE)  in 
an  effort  to  develop  a  proposed  data  interchange  form.  The 
proposed  interchange  form  [GG2]  has  been  used  by  several 
ERDA  laboratories  for  transporting  data  between  the 
laboratories.  Additional  work  on  development  of  interchange 
forms  has  been  pursued  by  the  Data  Base  Systems  Research 
Group  at  the  University  of  Michigan  [UT14]. 

Navathe  [RIO]  has  recently  reported  a  technique  for 
analyzing  the  logical  and  physical  structure  of  data  bases 
with  a  view  to  facilitating  the  restructuring  specification. 
Data  relationships  are  divided  into  identifying  and 
nonidenti fyi ng  types  in  order  to  draw  an  explicit  schema 
diagram.  The  physical  implementation  of  the  relationships 
in  the  schema  diagram  is  represented  by  means  of  a  schema 
realization  diagram.  These  diagrammatic  representations  of 
the  source  and  target  data  bases  could  prove  to  be  very 
useful  to  a  restructuring  user. 

6.2.2  Application  Program  Conversion.  So  far,  we  have 
concentrated  on  the  data  aspects  of  the  conversion  problem; 
it  is  necessary  to  deal  as  well  with  the  problems  of 
converting  the  application  programs  which  operate  on  the 
data  bases.  Program  conversion,  in  general,  may  be 
motivated  by  many  different  circumstances,  such  as  hardware 
migration,  new  processing  requirements,  or  a  decision  to 
adopt  a  new  programming  language.  Considerable  effort  has 
been  devoted  to  special  tools  such  as  those  to  assist 
migration  among  different  vendor's  COBOL  compilers,  and 
general  purpose  "decompilers"  that  have  been  developed  to 
translate  assembly  language  programs  to  equivalent  software 
in  a  high  level  language.  While  progress  has  been  made 
developing  special  purpose  tools  for  a  limited  program 
conversion  situation,  little  progress  has  been  made  in 
obtaining  a  solution  to  the  general  problem  of  program 
conversion.  With  this  fact  in  mind,  this  section  focuses  on 
the  modifications  to  application  programs  that  arise  as  a 
consequence  of  data  restructuring/conversion. 

Probl em  Statement.   There  are  three  types  of  data  bases 
which  can  at fectap plication  programs: 


alterations  to  the  data  base  physical  structure,  for 
example,  the  format  and  encoding  of  data,  or  the 
arrangement  of  items  within  records 

changes  to  the  data  base  logical  structure  —  either : 

a.  the  deletion  or  addition  of  access  paths  to 
accommodate  new  performance  requirements,  or 
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b.  changes  to  the  semantics  of  data,  for  example, 
modification  of  defined  relationships  between  record 
types  or  the  addition  or  deletion  of  items  within 
records 


migration  to  a  new  DBMS,  perhaps  encompassing  a  data 
model  and/or  data  manipulation  language  different 
from  the  one  currently  in  use 
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Changes  in  relationships  between  record  types,  such 
as  changing  a  one-to-many  association  to  a  many-to- 
many  association  or  vice-versa. 

Deletion  or  addition  of  data  items,  record  types,  or 
record  relationships. 

Changing  derivable  information  ("virtual  items")  to 
explicit  information  ("actual  items")  or  vice-versa. 

.   Changes   in   integrity,   authorization   or  deletion 
rul es . 

Various  properties  of  data  base  application  programs 
greatly  complicate  the  conversion  problem.  For  instance, 
many  data  base  management  systems  do  not  require  that  the 
record  types  of  interest  (or  possibly  even  the  data  base  of 
interest)  be  declared  at  compile  time  in  the  program;  rather 
these  names  can  be  supplied  at  run  time.  Consequently  at 
tne  compile  time,  incomplete  information  exists  about  what 
data  the  program  acts  on.  Other  troublesome  problems  occur 
when  programs  implicitly  use  characteristics  of  the  data 
which  have  not  been  explicitly  declared  (e.g.,  a  COBOL 
program  executes  a  paragraph  exactly  ten  times  because  the 
programmer  knows  that  a  certain  repeating  group  only  occurs 
ten  times  in  each  record  instance).  Complexity  is 
introduced   whenever   a   data   manipulation   language   is 
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intricately  embedded  in  a  host  language  such  as  COBOL.  The 
interdependence  between  the  semantics  of  the  data  base 
accesses  and  the  surrounding  software  greatly  complicates 
the  program  analysis  stage  of  conversion.  Because  of  these 
considerations,  substantial  research  has  been  devoted  to 
alternatives  to  the  literal  translation  of  programs.  In 
particular,  some  currently  operational  tools  utilize  source 
program  emulation  or  source  data  emulation  at  run  time  to 
handle  the  problem  of  incomplete  specification  of  semantics 
and  yet  still  yield  the  effects  of  program  conversion. 

Current  Approaches.  In  this  section,  we  discuss  two 
main  techniques  currently  employed  in  the  industry.  These 
techniques  are  commonly  used  but  unfortunately  not 
documented  in  the  form  of  publications. 

DML  Statement  Substitution 

The  DML  substitution  conversion  technique,  which  can  be 
considered  an  emulation  approach,  preserves  the  semantics  of 
the  original  code  by  intercepting  individual  DML  statement 
calls  at  execution  time,  and  substituting  new  DML  statement 
calls  which  are  correct  for  the  new  logical  structure  of  the 
data  base.  Two  IBM  software  examples  which  provide  this 
type  of  conversion  methodology  are  1)  the  ISAM  compatibility 
interface  within  VSAM  (this  allows  programs  using  ISAM  calls 
to  operate  on  VSAM  data  base),  and  2)  the  BOMP/DBOMP 
emulation  interface  to  IMS.  This  program  conversion 
approach  becomes  extremely  complicated  when  the  program 
operates  on  a  complex  data  base  structure.  Such  a  situation 
may  require  the  conversion  software  to  evaluate  each  DML 
operation  against  the  source  structure  to  determine  status 
values  (e.g.,  currency)  in  order  to  perform  the  equivalent 
DML  operation  on  the  new  data  base.  Generalization  of  this 
approach  requires  the  development  of  emulation  code  for  the 
following  cases:  maintain  the  run  time  descriptions  and 
tables  for  both  the  original  and  new  data  base 
organizations,  intercept  all  original  DML  calls,  and  utilize 
old-new  data  base  access  path  mapping  description  (human 
input)  and  rules  to  determine  dynamically  what  set  of  DML 
operations  on  the  new  data  base  are  equivalent  to  each 
specific  operation  on  the  source  data  base. 

Although  a  conceptually   straightforward   approach,  it 

has   several  drawbacks.   The  drawbacks  can  be  categorized  as 

degraded   efficiency  and   restricti veness .    Efficiency  is 

degraded  primarily  because  each  source  DML  statement  must  be 
mapped  into  a  target  emulation  program,  which  uses   the   new 

DBMS  to  achieve  the  same  results.   The  increased  overhead  in 

program   size   and/or   processing    requirements   can  be 
significant. 
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This  approach  suffers  from  the  same  types  of 
disadvantages  inherent  in  the  emulation  approach. 
Efficiency  problems  for  complex/extensive  data  bases  and 
programs  performing  extensive  data  accessing  can  make  this 
method  prohibitively  expensive  for  practical  utilization. 
This  technique  is  generally  found  as  a  "specific  software 
package"  developed  at  a  computer  installation  rather  than  as 
a  standard  vendor  supplied  package. 

Current  Research.  Differing  from  the  emulation  and 
bridge  program  approaches,  current  research  aims  towards 
developing  more  generalized  tools  to  automatically  or  semi- 
automatical  1  y  modify  or  rewrite  application  programs.  The 
drawbacks  of  the  existing  approaches  described  above  can  be 
avoided  by  rewriting  the  application  programs  which  would 
take  advantage  of  the  new  structure  and  semantics  of  a 
converted  data  base  and  by  using  a  general  system  to  do  the 
conversion  rather  than  using  ad  hoc  emulation  packages  and 
bridge  programs. 
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Research  on  application  program  conversion  is  still  in 
its  infancy.  Consequently,  very  few  published  papers  on 
this  subject  exist.  This  section  describes  a  handful  of 
works  in  the  order  of  the  dates  of  publication.  Mehl  and 
Wang  [PT6]  presented  a  method  to  intercept  and  interpret 
DL/1  statements  to  account  for  some  order  transformations  of 
hierarchical  structures  in  the  context  of  the  IMS  system. 
Algorithms  involving  command  substitution  rules  for  various 
structural  changes  have  been  derived  to  allow  the  correct 
execution  of  the  old  application  programs.  This  approach 
works  only  for  a  limited  number  of  order  transformation  of 
segments  in  a  logical  IMS  data  base.  Since  it  is  basically 
an  emulation  approach,  it  has  the  drawbacks  discussed  in  the 
previous  section. 
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The  work  by  Su  and  Reynolds  [PT15]  studied  the  problem 
of  high-level  sublanguage  query  conversion  using  the 
relational .model  with  SEQUEL  [Z5]  as  the  sublanguage,  DEFINE 
[SL7]  as  the  data  description  language  and  CONVERT  [R2]  as 
the  translation   language.    Algorithms   for   rewriting   the 
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type  which  changes  the  data  base   sema 
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Housel  extends  the  work  on  application  migration 
undertaken  at  the  IBM  San  Jose  Laboratory.  This  work  uses  a 
common  language  for  specifying  the  abstract  representation 
of  source  programs  as  well  as  for  specifying  the  data 
translation  operations.  The  language  is  a  subset  of  CONVERT 
with  some  of  Codd's  relational  operators  [GG4].  The 
operators  of  the  language  are  designed  to  have  a  simple 
semantics  and  convenient  algebraic  properties  to  facilitate 
program  transformation.  They  are  designed  to  handle  data 
manipulation  in  a  general  hierarchical  structure  called  a 
"form"  as  well   as   relational   tables.    In   this   system, 
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ram  transformation  is  dictated  by  the 
ations  applied  to  the  source  data  base 
1  assumes  that  the  inverse  of  these 
ators  exists;  i.e.,  the  source  data 
nstructed  from  the  target  data  base  by 
rse  operators  on  the  target  data  base. 


data   mapping 

The  proposed 

data  mapping 

base  can   be 

applying   some 

More  precisely, 


s  assumed  that  M'(T)  =  S  where  S  is  the  source  data 
,  T  is  the  target  data  base,  and  M  is  the  mapping 
tion.  Thus,  program  conversion  is  done  by  substituting 
inverse  M'(T)  into  the  specification  language  statements 

abstract  representation  of  the  source  program)  for  each 
rence  to  the  source  data  base.   This  process  is  followed 

simplification  procedure  to  simplify  the  resulting 
ements  (the  target  abstract  representation  of  the 
ram).  The  author  points  out  that  the  assumption  on  the 
tence  of  M'(T)  restricts  the  scope  of  the  conversion 
1  em  handled  by  the  proposed  approach. 


Presently,  the  Data  Base  Program  Conversion  Task  Group 
(DPCTG)  of  the  CODASYL  Systems  Committee  is  investigating 
the  application  group  conversion  problem.  The  group  is 
looking  into  various  aspects  of  the  problems  including 
decompilation  of  COBOL  application  programs,  semantic 
changes  of  data  bases  and  their  effects  on  application 
programs,  program  conversion  techniques  and  methodologies, 
etc  . 
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Current  Research  Directions.  The  current  research  has 
uncovered  several  problems  which  need  to  be  investigated 
further  before  the  implementation  of  a  generalized 
conversion  tool  can  be  attempted.  The  following  issues  are 
believed  to  be  important  for  future  research: 
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Data 
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a  se   ana  App 
Programs   Based   on   the   work   by  Su  and  Liu  [PT13J  and~the 
study  of  the  DPCTG  group,  it  is  quite  clear  that   a   program 
conversion   system   would   need   more   information  about  the 
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Some  researchers  think  that  this  would  be  the  preferred 
method  to  effect  DML/host  language  program  conversion.  It 
should  avoid  many  of  the  efficiency/ restrict  ion  drawbacks 
inherent  in  current  automated  methods,  while  being  more  cost 
effective  and  less  error  prone  than  current  manual  methods 
(e.g.,  program  rewrite). 
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6.2.3  Prototype  Conversion  Systems  Analysis.  This  section 
analyzes  tne  state  ot  the  art  ot  generalized  data  conversion 
systems.  It  summarizes  what  has  been  learned  in  the  various 
prototypes.  The  prototypes  have  yielded  encouraging 
results,  but  some  weak  points  have  also  emerged.  A  section 
below  lists  some  questions  that  remain  to  be  answered  and 
comments  on  additional  features  that  will  be  necessary  to 
enhance  usability.  The  following  section  on  Analysis  of 
Architecture  analyzes  some  implementation  issues  which  can 
affect  the  cases  where  a  generalized  conversion  system  can 
be  appl ied . 


Where  Do  We  

Secti"on   5".  772   have 
some  of  these  tests  were 


Stand.   The  prototype  systems  described   in 

been  used  in  a  few  conversions.   While 

made  on  "toy  files,"  a  few  of   the 


tests  involved  data  volumes  from  which  realistic  performance 
estimates  can  be  extrapolated.  This  section  will  summarize 
the  major  tests  that  were  done  with  each  of  the  prototypes. 

The  Penn  Translator  The  translator  developed  by  Ramirez 
at  the  University  of  Pennsylvania  [DT3,6]  processes  single 
sequential  files  to  produce  single  sequential  target  files. 
Facilities  exist  for  redefining  the  structure  of  source  file 
records,  reformatting  and  converting  accordingly. 
Conversion  of  the  file  can  be  done  selectively  using  user- 
defined  selection  criteria.  Block  size,  record  size,  and 
character  code  set  can  be  changed,  and  some  useful  data 
manipulation  can  be  included. 

The  translator  was  used  in  several  test  runs  on  an 
IBM/370  Model  165.  The  DDL  to  generated  PL/1  code  expansion 
ratio  was  1:4,  so  coding  time  was  reduced. 
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A  further  test  of  the  Penn  Translator  was  conducted  by 
Winters  and  Dickey  [TA1].  An  experiment  was  conducted 
comparing  a  conventional  conversion  effort  against  the  Penn 
Translator  (slightly  modified).  Two  source  files  stored  on 
IBM  1301  disks  under  a  system  written  for  the  IBM  7080  using 
the  AUTOCODER  language  were  converted  to  two  target  files 
suitable  for  loading  into  IMS/VS.  Much  of  the  data  was 
modified  from  one  internal  coding  scheme  to  another.  The 
conversion  required  changing  multiple  source  files  to 
multiple  target  files. 

The  conventional  conversion  took  seven  months  versus 
five  months  for  the  generalized  approach,  a  productivity 
improvement  of  roughly  thirty  percent.  Time  for  adapting 
the  translator,  learning  the  DDL,  and  adapting  to  a  new 
operating  system  is  included  in  the  five  month  figure. 
Without  these,  an  estimate  of  three  months  was  made  for  the 
conversion  using  the  generalized  approach. 

The  SDC  Trans! ator  The  translator  described  in  [R3,4] 
was  Tmp  1  emenTell  during  1975-1976.  The  translator  could 
handle  single,  hierarchical  files  from  any  of  three  local 
systems--TDMS,  a  hierarchical  system  which  fully  inverts 
files;  DS/2,  a  system  which  partially  inverts  files;  and 
ORBIT,  a  bibliographic  system  which  maintains  keys  and 
abstracts.  Data  Bases  were  converted  from  TDMS  to  ORBIT, 
from  TDMS  to  DS/2,  and  vice-versa,  and  from  sequential  files 
to  ORBIT.  TDMS  files  were  unloaded  using  an  unload  utility. 
Target  data  bases  were  loaded  by  target  system  load 
u  t  i  1  i  t  i  e  s  . 

The  total  effort  for  design  and  implementation  was 
about  three  man-years.  The  system  was  implemented  in 
assembly  language  on  an  IBM/370  Model  168,  and  occupied 
about  40  K-bytes,  not  including  buffer  space  which  could  be 
varied.  The  largest  file  tested  was  on  the  order  of  5 
million  characters  and  the  total  conversion  time  was  about  1 
minute  of  CPU  time  per  2.5  megabytes  of  data. 

The  work  was  discontinued  in  1976. 
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Tests  of  up  to  10,000  records  were  run.  Performance  of  15 
milliseconds  per  record  was  typical  (Honeywell  Series  6000 
Model  6080  computer).  The  prototype  has  been  used  in  a 
conversion/benchmark  environment  but  has  not  been  offered 
commercial ly . 

The  Michigan  Transl ator  Version  IIB,  Release  1.1  of  the 
Michigan  Translator  was  completed  for  the  Defense 
Communications  Agency  in  October  1977  [UT16].  It  offers 
complete  conversion/restructuring  facilities  for  users  of 
Honeywell  sequential,  ISP,  or  I-D-S/I  files.  Up  to  five 
source  data  bases  of  any  type  may  be  merged,  restructured  or 
otherwise  reorganized  into  as  many  as  five  target  data 
bases,  all  within  a  single  translation.  Data  Base 
description  is  accomplished  by  minor  extensions  to  existing 
I-D-S  DDL  statements.  Restructuring  specification  is  easily 
indicated  via  a  high  level  language.  Tests  performed  to 
date  included  a  conversion  of  a  150,000  record  I-D-S/I  data 
base  with  a  total  elapsed  time  of  24  hours  (500  milliseconds 
per  record).  A  given  translation  can  be  broken  off  at  any 
point  to  permit  efficient  utilization  of  limited  resources 
and  also  protect  against  system  failures.  The  user  is 
provided  with  the  capability  of  monitoring  translation 
progress  in  real  time. 
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Questions  Remaining  To  Be  Answered.  Given  that  several 
prototype  data  translation  systems  are  operational  in  a 
laboratory  environment,  there  is  a  little  question 
concerning  the  technical  feasibility  of  building  generalized 
systems.  The  remaining  questions  pertain  to  the  use  of  a 
generalized  system  in  "real  world"  data  conversions 
involving  a  wide  variety  of  data  structures,  very  large  data 
volumes,   and   significant   numbers   of  people.   Three  major 
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questions  to  be  resolved  are 


1.   Are  the  generalized   systems 

enough  to   be  used  in  real  conversions, 
what   will   it   take   to  make   them 
compl ete? 


functionally  complete 

and  if  not, 

functional ly 


2.  Can  the  people  involved  in  data  conversions  use  the 
languages?  What  additional  features  are  necessary 
to  enhance  usability? 


3.   Overall,  what  is   the   productivity 
with  the  generalized  approach? 


gai  n   avai 1 abl e 


Within  the  next  year,  prototype  systems  will  be 
exercised  on  a  variety  of  real-world  problems  in  data 
translation,  and  concrete  answers  to  these  questions  should 
be  available.  The  systems  being  further  tested  for  cost- 
effectiveness  are  the  Michigan  Data  Translator,  the  IBM  XPRS 
system,  and  the  Bell  Laboratories  ADAPT  system. 

To  date,  preliminary  results  have  been  promising.  A 
significant  sample  size  on  which  to  do  analysis  of 
productivity  gain  should  be  available  at  the  end  of  the  year 
of  testing. 


A  number  of  factors   must   be 
measuring   the  cost-effectiveness 
translator   versus   the 
These  factors  include: 


taken   into   account   in 

of  the  generalized  data 

conventional   conversion   approach. 


ease   of  learning   and   using  the   higher   level 
languages  which  drive  the  generalized  translators; 

availability  of  functional  capability  to  accomplish 
real-world  data  conversion  applications  within  the 
generalized  translators; 

overall  machine  efficiency; 

correctness  of  results  from  the  conversion; 

ability  to  respond  in  timely  fashion  to  changes  in 
conversion  requirements  (conversion  program 
"mai  ntenance" ) ; 

debugging  costs; 
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ability  to  provide  "bridge  back"  of   converted   data 
to  ol d  appl ications ; 

ability  to  provide  verification   of   correctness   of 
data  conversion; 

capabilities   for   detection   and   control   of   data 
errors . 


The  languages  used  to  drive  generalized  data 
translators  are  high-level  and  non-procedural;  they  provide 
a  "user-friendly"  interface  to  the  translators.  Since  the 
languages  are  high-level,  programs  written  in  them  have  a 
better  chance  of  being  correct.  Experience  to  date  with 
DEFINE  and  CONVERT,  the  languages  which  drive  XPRS,  has 
shown  that  users  can  learn  these  languages  within  a  week;  it 
has  also  shown  that  some  practice  is  necessary  before  users 
start  thinking  about  their  conversion  problem  in  non- 
procedural rather  than  procedural  terms. 

In  early  test  cases,  the  languages  which  drive 
generalized  data  translators  have  been  found  to  be 
functionally  adequate  for  many  common  cases.  In  those  cases 
lacking  a  feature,  a  "user  hook"  facility  is  often  provided. 
However,  forcing  a  user  to  revert  to  a  programming  language 
hook  defeats  the  purpose  of  the  high  level  approach,  and 
interfacing  the  hook  to  the  system  requires  at  least  some 
knowledge  of  system  interfaces.  Thus,  high  level  languages 
must  cover  the  vast  majority  of  the  cases  in  order  to 
succeed;  otherwise,  users  will  perceive  little  difference 
over  conventional  approaches. 

Facilities  for  detecting  and  controlling  data  errors  in 
the  generalized  systems  are  very  important,  and  most  of  the 
prototypes  do  not  yet  do  a  complete  job  in  this  area. 
However,  the  generalized  packages  offer  an  opportunity  for 
generalized,  high  level  methods  for  dealing  with  data  errors 
during  conversion,  and  it  could  well  be  that  once  these 
error  packages  are  developed,  they  will  contribute  to  even 
larger  productivity  gains  than  have  been  experienced  to 
date. 

The  high-level  language  approach  to  driving  generalized 
translators  should  provide  the  ability  to  respond  to  changes 
in  conversion  requirements  with  relative  ease.  Since  large 
conversions  often  take  one  or  more  years,  it  is  not  unusual 
for  the  target  data  base  design  to  change  or  for  new 
requirements  to  be  placed  on  the  conversion  system.  In 
other  words,  in  a  large  conversion  effort,  the  programs  are 
not   as   one   shot"   as   is   commonly   believed.    In  large 


conversions,  the  savings  in 
could  be  significant. 


conversion   program   maintenance 
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Generalized  systems  can  also  be  used  to  map  target  data 
back  to  the  old  source  data  form,  assuming  the  original 
conversion  was  information-preserving.  This  capability 
provides  a  means  for  verifying  the  correctness  of  the  data 
conversion.  In  addition,  this  capability  can  be  used  as  a 
"bridge  back"  to  allow  users  to  continue  to  run  programs 
which  have  not  yet  been  converted  against  the  data  in  the 
old  format.  Using  a  generalized  system  in  this  way  allows 
phased  conversion  of  programs  without  impacting  user  needs 
during  the  conversion  period. 

In  an  environment  where  a  generalized  translator  is 
used  regularly  as  a  tool  for  conversion,  costs  associated 
with  the  debugging  phase  should  be  decreased.  Common, 
debugged  functional  capabilities  will  be  utilized,  whereas 
it  is  unusual  in  the  conventional  approach  for  common 
conversion  modules  to  be  developed.  Thus,  each  new 
conversion  system  requires  debugging. 

Usabil ity  The  usability  of  generalized  data  translation 
systems  must  also  be  evaluated.  Experience  to  date 
indicates  that  the  languages  are  easy  to  learn  and  use. 
However,  it  would  be  wrong  to  think  that  these  prototypes 
are  mature  software  products  or  that  they  can  be  used  in  all 
conversions.  This  section  discusses  some  of  the  unanswered 
questions  with  respect  to  usability  of  the  current  data 
conversion  systems. 

One  question  concerns  the  level  of  users  of  the 
generalized  languages.  Current  prototypes  have  been  used  by 
application  specialists  and/or  members  of  a  data  base 
support  group.  The  systems  have  not  yet  been  used  by 
programmers,  and  the  question  remains  whether  programmers 
(as  opposed  to  more  senior  application  specialists  and 
analysts)  will  be  able  to  use  the  systems  productively. 
There  is  no  negative  data  on  this  point;  the  systems  have 
not  been  used  widely  enough. 
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macro  library  link  may  not  necessaril 
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Another  area  where  a  user  may  have  to  expend  effort  is 
in  the  unload  step  of  the  data  conversion  process.  The  data 
description  languages  used  to  drive  the  read  step  have  a 
limited  ability  to  deal  with  data  at  a  level  close  to  the 
hardware  (e.g.,  pointers,  storage  allocation  bit  maps, 
etc.).  Generally  one  assumes  that  a  system  utility  program 
can  be  used  to  unload  source  data  and  remove  the  more 
complex  internal  structures.  Another  alternative  is  to  run 
the  read  step  on  top  of  an  existing  access  method  or  data 
base  management  system  with  the  accessing  software  removing 
the  more  complex,  machine  dependent  structures.  While 
acceptable  alternatives  in  a  great  many  environments, 
including  most  COBOL  environments,  some  cases  may  exist 
where  neither  approach  will  work.  For  example,  a 
load/unload  utility  may  not  exist,  or  a  file  with  embedded 
pointers  which  was  accessed  directly  by  an  assembly  language 
program  might  not  be  under  the  control  of  an  access  method. 
For  these  cases,  the  user  is  faced  with  complexity  during 
the  unload  step.  The  complexity  associated  with  accessing 
the  data  would  appear  to  be  a  factor  for  either  the 
conventional  methods  or  for  the  generalized  approach. 
However,  in  cases  such  as  those  above,  some  special  purpose 
software  may  have  to  be  developed.  Note  that  some  research 
LSL8]  has  examined  the  difficulty  of  extending  data 
description  languages  to  deal  directly  with  these 
complex  cases  and  has  concluded  that  providing  the 
description  language  with  capabilities  to  deal  with 
complex  data  structures  greatly  complicates 
implementation  and  has  an  adverse  affect  on  usability. 
Thus,  special  purpose  unload  programs  will  continue  to  be 
required  to  deal  with  some  files. 

Analysis  of  Architectures.  This  section  discusses  some 
ot  the  different approaches  that  have  been  taken  in 
implementing  the  prototype  data  conversion  systems.  The 
objective  is  to  analyze  some  of  the  performance  and 
usability  issues  raised  by  the  prototypes. 
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In  data  conversion  systems,  as  in  other  software,  an 
implementation  based  on  interpretation  can  be  expected  to 
run  considerably  more  slowly  than  one  based  on  generation 
and  compilation.  Initial  experience  with  prototype  data 
translators  has  shown  that  there  is  much  repetitive  work, 
strategies  for  which  can  be  decided  at  program 
compilation/generation  time.  Also,  there  is  a  good  deal  of 
low  level  data  handling,  such  as  item  type  conversions. 
Thus,  those  implementations  based  largely  on  an  interpretive 
approach  run  more  slowly,  and  the  ability  to  vary  bindings 
at  run  time  does  not  appear  to  be  necessary.  Interpretation 
was  chosen  in  the  prototypes  for  ease  of  implementation,  and 
in  the  future  it  can  be  expected  that  a  compilation-based 
approach  or  a  mixture  of  compilation  with  interpretation 
will  be  the  dominant  implementation  architecture.  However, 
for  medium  scale  data  bases,  the  machine  requirements  of  the 
interpretive  data  conversion  prototypes  are  not 
unreasonable,  and  overall  productivity  gains  are  still 
possi  bl e. 
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Performance  measurements  with  conversion  systems  based 
he  generative  approach  indicate  that  generalized  systems 
be  quite  competitive  with  customized  programs.  In  one 
,  the  program  generated  by  the  data  conversion  system 
slightly  faster  than  a  "customized"    program   which  had 

written  to  do  the  same  job.  However,  this  example 
d  well  be  the  exception  and  it  would  be  naive  to   expect 

in  general.  The  reason  generalized  packages  can  be 
etitive  is  that  they  often  have  internal  algorithms 
h  can  plan  access  strategies  to  minimize  I/O  transfer 
or  multiple  passes  over  the  source  data.  "Customized" 
ersion  programs  written  in  a  conventional  programming 
uage  often  are  not  carefully  optimized,  since  the 
ctation  is  that  the  programs  will  be  discarded  when  the 
ersion  is  done. 
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A  second  architectural  difference  involves  the  use  of 
an  underlying  DBMS  or  not.  In  both  the  Penn  Translator  and 
XPRS,  the  generated  PL/1  program,  then  executing,  accesses 
sequential  files,  performs  the  restructuring,  and  writes 
sequential  files.  On  the  other  hand,  the  Michigan  Data 
Translator  functions  as  an  application  program  running  on  a 
network  structured  data  base  management  system.  Thus,  the 
interpreter  makes  calls  to  the  underlying  DBMS  to  retrieve 
data  during  restructuring  and  puts  restructured  data  into 
the  new  data  base . 


The  two  approaches  offer  different  tradeoffs.  For 
example,  the  Michigan  Data  Translator  can  make  use  of  the 
existing  extraction  capabilities  of  a  DBMS  and  perform 
partial  translations  easily.  In  addition,  since  it  operates 
directly  within  the  network  data  model,  a  user  does  not  have 
to  think  of  "unloading"  data  to  a  file  model  and  then 
reloading  it  back;  rather,  the  user  describes  a  network  to 
network  restructuring  much  more  directly. 
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•  ~.  1WUJ  .s.uuo  wi  V.UMVCISIUII  buudiions.   ror  example,  it 
possible  to  interface  the  "file-oriented"  conversion  systei 
to  run  as  application  programs  on  top  of  existing  data   ba: 


one  can  expect  that  data  conversion 
systems  will  offer  a  variety  of  interfaces  to  accommodate 
various  kinds  of  conversion  situations.   For  example,  it   is 

»ms 
ig  data  base 
management  systems.  It  is  also  possible  to  develop  "reader 
programs"  to  load  non-data  base  data  into  conversion  systems 
based  on  a  DBMS.  In  addition,  more  automated  interfaces  to 
data  dictionary  packages  can  be  expected  in  order  to  improve 
usability  and  obviate  the  need  for  multiple  data 
def i nitions . 


One  possible  performance  problem  with  generalized 
conversion  systems  lies  in  the  unload  phase.  For  reasons  of 
usability,  generalized  conversion  systems  usually  rely  on  an 
unload  utility  program  to  access  the  source  data,  thus 
isolating  the  conversion  package  from  highly  system  specific 
data.  A  potential  problem  with  this  approach  is  that  the 
unload  package  may  not  make   good   use   of  existing   access 
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y  Detailed  performance  and  productivity  figures 
onversions  should  be  available  in  about  one  year, 
s  are  that  machine  efficiency  of  the  generalized 
ased  on  a  generation/compilation  approach  will  be 
(no  worse  than  a  factor  of  2)  when  compared  with 
1  conversion  programs.  Additional  enhancements 
usability  can  be  expected,  especially  in  the 
ata  error  detection  and  control  and  interfaces  to 
nary  software.  If  the  savings  in  conversion 
alysis  and  coding  times  —  often  fifty  percent  or 
onfirmed,  then  the  generalized  conversion  systems 
dy  for  extensive  use." 


6.3   OTHER  FACTORS  AFFECTING  CONVERSION 

In  this  section  we  look  at  the  conversion  problem  from 
two  aspects.  First,  we  address  the  quest ion--What  can  we  do 
today  to  lessen  the  impact  of  a  future  conversion?  Second, 
we  look  to  the  future  to  see  what  effects  future  technology 
and  standards  will  have  on  the  conversion  process. 

6.3.1  Lessening  the  Conversion  Effort.  In  order  to  identify 
guidelines  for  both  reducing  the  need  for  conversion  and  for 
simplifying  conversions  which  are  required,  one  must 
consider  the  entire  application  software  development  cycle 
because  poor  application  design,  poor  logical  data  base 
design,  inadequate  use  of  and  inappropriate  DBMS  selection 
could  each  lead  to  an  environment  which  may  prematurely 
require  an  application  upgrade  or  redesign.  This  redesign 
could,  in  many  cases,  require  a  major  data  base  conversion 
effort . 
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The  set  of  guidelines  specified  below  is  not  intended 
as  a  panacea.  Instead,  it  is  meant  to  make  designers  aware 
of  strategies  which  make  intelligent  use  of  current 
technology.  It  is  doubtful  that  all  conversions  could  be 
avoided  if  a  project  adhered  strictly  to  these  proposed 
guideliines.  However,  adherence  to  the  principles  set  forth 
by  these  guidelines  could  certainly  reduce  the  probability 
of  conversion  and,  more  importantly,  simplify  the 
conversions  that  are  required. 


With  respect  to  application  design  and  implementation, 
the  more  the  application  is  shielded  from  system  software 
and  hardware  implementation  details,  the  easier  it  becomes 
for  a  conversion  to  take  place.  For  example,  a  good 
sequential  access  method  hides  the  difference  between  tapes, 
disks,  and  drums  from  the  application  programs  which  use  the 
access  method. 

The  logical  data  base  design  should  be  specified  with  a 
clear  understanding  of  the  information  environment.  A  good 
logical  data  base  design  reduces  the  need  to  restructure 
because  it  actually  models  the  environment  it  is  meant  to 
serve.  Introduction  of  data  dependencies  in  the  data 
structure  should,  if  possible,  be  kept  to  a  minimum.  An 
analysis  of  the  tradeoffs  between  system  performance  and 
likelihood  of  conversion  should  definitely  be  made. 


Selecting  the  wrong  or  non-optimal  data  base  management 
system,   given   the   application  requirements,  is  also 
problem  which  can  lead  to  unnecessary  and   large 
efforts.   The   prospective   user   of  a   DBMS 
example,   carefully   evaluate   the   data 
characteristics  of  a  proposed  DBMS. 
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The  underlying  principle  of  the  guidelines  which  follow 
is  that  decisions  can  be  made  at  the  system  design  and 
implementation  stages  which  are  crucial  to  the  stability  of 
theapplications. 
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frequent  conversions  will  be  necessary. 
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Requirements  analysis  should  focus  o 
should  minimize  constraints  be in 
ical  environment  since  it  can  disto 
of  the  application   system's  tru 
uence  of  the  physical  environment  sho 
ndarily,   in   order  that  the  designe 
resulting  compromises  to  the  logical 
not  intended  to  imply  that  considerat 
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of  requirements   that   are   impossibl 
ting  physical  and  cost  constraints. 
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Program  Design  Guide! ines  Three 
otivate  this  discussion   oT  appli 
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underlying   principles 
cation   program  design. 


are 


design  for  maintainability 

design  for  the  application 

data  independence 

Keeping  sight  of  all  of  these  during  the  design  of  the 

application   program  will  lessen   conversion   effects  by 

rendering  the  application  as  free  as  possible  from   physical 
consi  derat i  ons . 


Designing  for  maintainability  implie 
application  should  be  written  in  a  high-level 
a  syntax  that  permits  good  program  structure 
programming  techniques  such  as  top-down  prog 
implementation  should  be  used  throughout.  The 
be  modular  with  relatively  small,  functio 
programs.  The  programs  should  all  be  well 
organized  for  readability.  Design  reviews 
walkthroughs  also  help  to  expose  errors  in 
design  and  "holes"  in  the  application  log 
stage.  It  has  been  well  documented  that  thes 
ease  making  program  modifications. 
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One  error  which  is  often  made  in  designing  programs  in 
a  DBMS  environment  is  to  let  the  capabilities  of  the  DBMS 
drive  the  design  rather  than  the  application.  This  design 
error  can  yield  programs  which  are  unnecessarily  dependent 
upon  the  features  of  a  specific  DBMS.  For  example,  in 
System  2000  one  can  use  a  tree  to  represent  a  many-to-many 
relationship  instead  of  using  the  LINK  feature.  The 
parent/child  dichotomy  that  results   is  an  efficient  but 
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arbitrary  contrivance  that  cannot  easily  be  undone  later  on. 
ine  key  principle  here  is  to  concentrate  on  what  results  are 
desired  rather  than  on  the  implementation  details  of 
achieving  these  results.  Simplicity  and  generalization  of 
the  design  will  provide  a  very  high  level  of  interface  to 
the  application  programmer  which  will,  in  turn,  minimize  the 
total  amount  of  software,  provide  the  greatest  degree  of 
portability,  maintainability,  devide  independence,  and  data 
independence. 


of 


Of  extreme  importance  in  program  design  is   the   notion 
data   independence;   i.e.,   insulating   the   application 
program  from  the  way  the  data  is  physically  stored. 

Layered  Design 


That  is,  designing  the  application  as  a   series   of   layers 
each   of  which   communicates  with  the  system  at  a  different 
level  of  abstraction.   One  can  visualize  this  as  an  "onion," 

ire 
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he 


level  of  abstraction.   One  can  visualize  this  as  an  "onion 
with   hardware   as   its  core  and  layers  of  successively  moi 
sophisticated   software   at   the   outer   layers.    The   use 
interacts   with   the   outermost   skin   of   the  onion,  at  tl 
highest  level  of  abstraction. 
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If  application  programs  are  written 
rs  of  the  onion,  then  these  programs 
nderstand  and,  therefore,  easier  to 

programs   written   at   lower   laye 
oduction  of  a  new  mainframe  will  requ 
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We  can  thus  summarize  the  goal 
follows: 


of   program   design   as 


to   provide   the    highest 
interface  to  the  program 


to   maximize 
character!'  sties 


possibl e   appl i cat  ion 


program    independence   from   the 
of   the  mainframe,  peripherals,  and 
data  base  organization 
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.   to  maximize  portability  of  the   application   program 
through  the  use  of  high-level  languages 

to  maintain  a  clean  program/data  interface 

Programming  Techniques 

The  previous  sections  of  this  chapter  have  focused  on 
the  design  decisions  which  should  be  made  to  alleviate  the 
conversion  problem.  However,  regardless  of  how  noble  these 
goals  are,  poor  implementation  decisions  can  go  a  long  way 
towards  diminishing  the  returns  of  a  good  design.  Equally 
important  to  intelligent  design  is  a  set  of  programming 
techniques  and  standards  which  prohibit  programmers  from 
introducing  dependencies  in  code.  For  example,  a  "clever" 
programmer  may  introduce  a  word  size  dependency  in  a  program 
by  using  right  and  left  shifts  to  effect  multiplication  and 
division.  Of  course,  there  are  no  hard  and  fast  safeguards 
against  using  tricky  coding  techniques;  an  effort  must  be 
made  to  make  the  programmer  conscious  of  the  consequences  of 
this  kind  of  coding.  In  particular,  a  programmer  should  not 
be  allowed  to  jump  across  layers  of  the  onion,  such  as  using 
an  access  method  to  read  or  write  directly  data  bases. 

Data  Base  Design.  Perhaps  the  most  costly  mistake  a 
designer  can  maTe  is  an  error  in  the  data  base  design 
because  it  has  a  direct  effect  on  the  information  that  is 
derivable  and  the  application  programs  that  are  created. 
Incorrect  or  unanticipated  requirements  can  lead  either  to 
information  deficient  data  bases  or  overly  complex  and 
general  design.  An  inadequate  logical  design  has  the 
potential  for  complex  user  interfaces  or  extremely  long 
access  time.  A  poor  physical  design  can  lead  to  high 
maintenace  and  performance  costs.  Unfortunately,  data  base 
design  is  still  an  art  at  the  present  time.  Two  surveys 
report  the  results  in  the  area  to  date.  Novak  and  Fry 
[DL26]  survey  the  current  logical  data  base  design 
methodology  and  Chen  and  Yao  [DL34]  review  data  base  design 
in  general.  The  work  of  Bubenko  [DL31]  in  the  development 
of  the  CADIS  system  and  the  abstraction  and  generalization 
techniques  of  Smith  and  Smith  [DL29,30]  show  promise. 

An  accurate  logical  design  can  still  be  unnecessarily 
data  dependent.  Dependencies  are  inadvertently  or 
deliberately  introduced  in  the  interest  of  improving  system 
performance.  In  essence,  "purity"  is  compromised  to  gain 
processing  efficiences.  Since  optimization  is  a  worthwhile 
goal,  insisting  on  absolute  purity  may  be  unreasonable. 
However,  the  data  base  designer  should  at  least  be  aware  of 
contrivances  and,  therefore,  be  in  a  position  to  evaluate 
the  relative  effects  a  design  decision  may  have.  Designers 
should   become  sensitive  to  their  decisions  by  asking:   "How 
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will  the  data  model  be  affected  by  a  future  change  in 
performance  requirements?  Have  I  done  a  reasonable  job  in 
insulating  applications  from  data  structure  elements  that 
are  motivated  strictly  by  performance  considerations?" 

Some  examples  of  induced  data  dependencies   in   logical 
data  base  design  which  may  impact  upon  conversion  are: 


The  use  of  owner-coupled  sets  in  DBTG  to  implement 
performance-oriented  index  structures  or  orderings 
on  records. 

Storing  physical  pointers  (or  data  base  keys)  in  an 
information  field  of  a  record 


.   Combining  segment  types   (in   DL/1)   to   reduce  the 
amount  of  I/O  required  to  traverse  a  data  base. 

DBMS  Utilization  and  Selection.   Selection   of  a   DBMS 

on  conversion  requirements.   Of 
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DBMS  prospects  should  evaluate  the  data  independence 
characteristics  of  a  proposed  product.  Systems  are 
preferred  which  support  an  "external  schema"  or  "subschema" 
feature  which  permits  the  record  image  in  the  application 
program  (the  user  work  area)  to  differ  significantly  from 
the  data  base  format.  However,  the  subschema  concept  is 
only  one  aspect  of  data  independence.  In  general,  it  is 
necessary  to  determine  in  what  ways  and  to  what  extent  the 
application  interface  is  insulated  from  performance  or 
internal  format  options.  For  instance,  will  programs  have 
to  be  modified  if: 
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a  decision  is  made  to  add  or  delete  an  index? 

the   amount   of   space   allocated   to   an   item   is 
increased  or  decreased? 

chains  are  replaced  by  pointer  arrays? 

Other  conversion  related  questions  about   DBMS  products 
include  the  following: 


Are  there  adequate  performance  and  formatting 
alternatives?  Are  there  too  many  (i.e., 
unproductive  or  incomprehensible)  tuning  options? 
Are  there  adequate  performance  measurement 
techniques  and  tools  to  guide  the  exercise  of  these 
choices? 

Does  the  system  automatically  convert  a  populated 
data  base  when  a  new  format  option  is  selected? 

Aside  from  tuning,  does  the  DBMS  gracefully 
accommodate  at  least  simple  external  changes  such  as 
adding  or  deleting  a  record  or  item  type? 

Are  there  other  useful  high  level  facilities 
associated  with  or  based  on  the  DBMS,  such  as  a 
report  writer,  query  processor,  data  dictionary, 
transaction  monitor,  accounting  system,  payroll 
system,  etc.? 

Is  there  a  utility  for  translating  the  data  base 
into  an  "interchange  form;"  i.e.,  a  machine 
independent,  serial  stream  of  characters? 

Is  the  vendor  committed  to  maintaining  the  product 
across  new  operating  system  and  hardware 
releases/upgrades?  Conversely,  is  the  vendor 
prepared  to  support  the  product  in  order  released  of 
the  operating  system,  so  the  user  will  not  be  forced 
to  upgrade? 

What  hardware  environments  are  currently  supported 
and  what  is  the  vendor's  policy  regarding  conversion 
to  another  manufacturer's  mainframe? 

What  programming  language  interfaces  are  available? 
Gan  the  same  DBMS  features  be  used  if  there  is  a 
migration,  say,  from  COBOL  to  PL/1? 
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user 


How  intelligent  is  the  system's  technique  for 
organizing  data  on  the  media?  Specifically,  will 
performance  deteriorate  at  an  inordinate  rate  as 
updating  proceeds?  How  often  will  reorganization 
(cleanup)  be  required?  Does  the  DBMS  have  a  built- 
in  reorganization  utility?  How  does  the 
determine  the  optimal  time  to  reorganize? 

Are  the  language  facilities  and  data  modeling 
facilities  of  DBMS  adequate  for  the  anticipated  long 
term  requirements  of  the  enterprise?  What  is  the 
risk  of  having  to  convert  to  a  new  DBMS? 

Likewise,  are  the   performance  characteristics  and 
internal   storage   structure  limitations  adequate  to 
meet  the  long   term   requirements   (response   times 
data  base  sizes)  of  the  enterprise? 

Are  there  facilities  to  assist  the  user  in 
converting  data  from  a  non-DBMS  environment  or  from 
another  DBMS?  For  instance,  can  a  data  base 
loaded  from  one  or  more  user  defined  files? 


be 


6.3.2  Future  Technologies/Standards  Impact. 

In  this  section  we  discuss  trends  in  computer  hardware 
technologies,  DBMS  software  directions,  and  standards 
development,  and  consider  their  impact  on  data  and  program 
conversion.  We  intend  to  make  the  reader  aware  of  what  to 
expect  in  terms  of  conversion  problems  rather  than  give  a 
complete  assessment  of  future  technologies.  Therefore  we 
discuss  only  technologies  and  standards  that  will  impact 
conversion  problems. 


The  first  three  parts  discuss  the   areas   of  hardware 
software,   and   standards   and  their  impact  on  conversion 
some  detail.   The  last  part  summarizes  the 
our  assessment  without  going  into  detailed 
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reasoni  ng . 
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Hardware  and  Architectural  Technologies.  The  cost  and 
performance  of  processor  HTgic  iTPTa  memory  continue  to 
improve  at  a  fast  rate.  As  a  result,  overhead  costs  are 
more  acceptable,  especially  when  such  costs  save  people's 
time  and  work,  and  provide  user  oriented  functions  that  do 
not  require  a  computer  expert.  In  particular,  one  can  now 
trunk  about  using  generalized  conversion  tools  not  only  when 
it  is  required  as  a  result  of  hardware  or  software  changes 
Dut  also  as  a  result  of  a  changing  application  that  requires 
a  new  more  efficient  data  base  organization.  What  could 
have  been  a  prohibitive  cost  for  a  data  base  conversion 
tne  past,  may  not  be  a  major  factor  in  the  future. 


i  n 
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same  time,   the   cost/performance   improvement 


to  the  proliferation  of  data  bases  and  therefore 
the  need  of  generalized  conversion  tools.  The 
effective  is  the  process  of  accessing  and 
data,  the  more  data  is  collected  on  computers, 
in  hardware  (as  well  as  software)  technologies 
create  more  need  for  data  and  program  conversion.  In 
addition,  the  emergence  of  new  technologies,  such  as 
communication  networks,  add  another  level  of  sophistication 
to  the  way  that  data  can  be  organized  and  used.  Distributed 
data  bases,  where  multiple  data  bases  (or  subsets  of  data 
bases)  may  reside  on  different  machines,  require  tools  for 
the  integration  and  the  correlation  of  data.  Invariably, 
data  will  need  to  move  from  system  to  system  dynamically, 
possibly  moving  between  different  hardware/software  systems. 
In  this  environment,  generalized  tools  for  dynamic 
conversion  will  become  a  necessity. 


In  recent  years,  two  promising  approaches  to  data 
management  hardware  technologies  have  been  pursued.  One  is 
thi 

backend  data  manag<_ 
both  approaches  can  help  simplify  the  conversion  problem. 


nagemeni  naraware  lecnnuiuyies  nave  ueen  pu.oucu.  ^i.v.  >- 
le  specialized  data  management  machine  and  the  other  is  the 
ickend  data  management  machine.   As  will  be  explained  next, 


The  specialized  data  management  hardware  is  based  on 
the  idea  of  using  some  kind  of  an  associative  memory  device, 
a  device  that  can  perform  a  parallel  access  to  the  data 
based  on  its  content.  Such  a  device  eliminates  the 
necessity  for  organizing  the  internal  structure  of  a  data 
base  using  indexes,  hash  tables,  pointer  structures  ,,  etc  .  , 
which  are  primarily  used  for  fast  access.  As  a  result,  the 
data  can  be  essentially  stored  in  its  external  logical  form, 
and  the  data  management  system  can  use  a  high  level  language 
based  on  the  logical  data  structure  only.  The  conversion 
process  is  simplified  since  data  is  readily  available  in  its 
logical  organization.  Referring  to  the  terminology  used  in 
previous  sections,  the  functions  of  unloading  and  loading  of 
the  data  base  can  be  greatly  simplified.  Also,  no 
restructuring  will  be  required  because  of  a  change  in  data 
base  use,  since  the  physical  data  base  organization  can  be 
to  a  large  degree  independent  of  its  intended  use.  In 
addition,  the  program  conversion  problem  is  simplified  as  a 
result  of  the  program  interfacing  to  the  DBMS  using  a  high 
level  logical  language. 

Similar  benefits  can  be  achieved  if  backend  machines 
are  used.  A  backend  machine  is  a  special  processor 
dedicated  to  managing  storage  and  data  base  on  behalf  of  a 
host  computer.  The  primary  motive  for  the  backend  machine 
is  to  off-load  the  data  management  function  from  the  host  to 
a  specialized  machine  that  can  execute  this  function  at  much 
lower  cost.   From  a  conversion  standpoint,  the  separation  of 
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data  management  functions  from  the  host  promotes  the  need 
for  a  high  level  logical  interface  that  provides  the 
advantages  discussed  above.  Another  advantage  is  that  it  is 
possible  to  migrate  from  one  host  machine  to  another  without 
affecting  the  data  bases  and  their  management,  alleviating 
the  need  for  data  conversion  if  the  same  backend  machine 
used  with  the  new  host. 


i  s 


Mass  storage  devices,  such  as  the  video  disks,  make 
storing  very  large  data  bases,  in  the  order  of  10  to  the 
10th  power  characters,  cost  effective.  Converting  large 
data  bases  of  this  size  compounds  the  cost  considerations 
merely  by  the  processing  of  this  large  amount  of  data.  As  a 
result,  such  data  bases  will  tend  to  stay  in  the  same 
environment  for  longer  periods  of  time.  The  use  of 
specialized  data  management  machines  or  dedicated  backend 
machines  in  conjunction  with  these  mass  storage  devices  can 
help  postpone  the  need  for  data  base  conversion. 


Finally, 
minicomputers 
DBMSs   now  exist 


we  should  mention  the  growing  use  of 
supporting  data  management  functions, 
on  many  minicomputers,  with  more 
forthcoming.  The  proliferation  of  minicomputers  which 
support  data  bases  can  only  increase  the  needs  for 
generalized  conversion  tools. 
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Much  of  the  work  over  the 
area  has  concentrated  on 
e  logical  structure  of 
anization.  This  concept, 
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At  the  user  end  of  the  spectrum,  it  seems  reasonable  to 
assume  that  the  diversity  of  data  models  (network, 
relational,  hierarchies  and  other  views  that  may  be 
developed  in  the  future)  will  be  required  for  many  more 
decades.  This  is  especially  true  since  there  are  problem 
areas  that  seem  to  map  more  naturally  into  a  certain  model. 
Furthermore,  it  is  often  the  case  that  users  do  not  agree  on 
the  same  model  for  a  given  problem  area.  Obviously,  this 
state  of  affairs  only  accentuates  the  need  to  generalize 
conversion   tools   that   can  restructure  data  bases  from  one 
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model  to  another.  Even  with  the  development  of  large  scale 
associative  memories,  data  structures  will  likely  provide 
economic  rationales  for  their  contrived  use.  Another 
possibility   is  the   use   of  a  common  underlying  data  model 

However,  this 


that  can  accommodate  any  of  the  user  views, 
approach  will  still  require  some  type  of  a 
conversion  process  between  the  common  view  and  each 
possi  bl e  user  vi  ews . 


dynamic 
of  the 


Standards  Devel opment .  There  is  much  work  and 
controversy  fn  devel opi  ng  standards  for  DBMS.  Standards 
that  are  oriented  to  determine  the  nature  of  the  DBMS  are 
hard  to  bring  about  even  in  a  highly  controlled  environment 
because  of  previous  investment  in  application  software  and 
data  base  development,  and  because  of  disagreement.  For 
example,  there  is  still  much  controversy  whether  the  network 
model  proposed  by  the  CODASYL  committee  is  a  proper  one.  It 
seems  reasonable  to  assume  that  there  will  always  be  non- 
standard DBMSs.  Further,  even  if  such  a  standard  can  be 
adopted,  different  DBMS  implementations  will  still  exist, 
resulting  in  different  physical  data  bases  for  the  same 
logical  data  base.  In  addition,  one  can  safely  assume^  that 
restructuring  because  of  application  needs  will  still  be 
necessary,  and  that  changes  in  the  standard  itself  may 
require  conversion. 

A  standard  that  is  more  likely  to  be  accepted  is  one 
that  affects  only  the  way  of  interfacing  to  a  DBMS.  In 
particular,  from  a  conversion  standpoint,  a  standard 
interchange  data  form  (SIDF)  will  be  most  useful.  A  SIDF  is 
a  format  not  unlike  a  load  format  for  DBMSs.  Any  advanced 
DBMS  has  a  load  utility  that  requires  sequential  data  stream 
in  a  pre-speci f i ed  format.  If  a  standard  for  this  format 
can  be  agreed  upon,  and  if  all  DBMSs  can  load  and  unload 
from  and  to  this  format,  then  the  need  for  reformatting  (as 
described  earlier)  is  eliminated.  The  conversion  process 
can  be  reduced  to  essentially  restructuring  only,  given  that 
unload  and  load  are  part  of  the  DBMS  function.  A 
preliminary  proposal  for  such  a  standard  was  developed  by 
the  ERDA  Inter-Working  Group  on  Data  Exchange  (IWGDE)  [GG2]. 
However,  it  is  only  designed  to  accommodate  hierarchical 
structures.  Consideration  is  now  being  given  to  the 
extension  of  the  standard  to  accommodate  more  general 
structures  (i.e.,  networks  and  relations).  We  believe  that 
there  are  no  technical  barriers  to  the  development  of  a 
SIDF,  and  that  putting  such  a  standard  to  use  would 
alleviate  a  major  part  of  the  data  conversion  process. 

Summary.  The  rationale  for  the  points  summarized  below 
appear  in  the  previous  parts  of  this  section.  We  will  only 
state  here  our  assessment  of  the  impact  on  conversion 
probl ems . 
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How  do  those  automated  checkout  counters,  gas  pumps 
credit  offices,  and  banking  facilities  work?  What  every 
consumer  should  know  about  the  modern  electronic  sys- 
tems now  used  in  everyday  transactions  is  explained  in 
a  12-page  booklet  published  by  the  Commerce  Depart- 
ment s  National  Bureau  of  Standards. 

Automation  in  the  Marketplace  (NBS  Consumer  Informa- 
tion Series  No.  10)  is  for  sale  by  the  Superintendent  of 
Documents,  U.S.  Government  Printing  Office,  Washington 
D.C.  20402.  Price:  90  cents.  Stock  No.  003-003-01969-1 


"AUTOMATION  IN  THE  MARKETPLACE" 
A  Consumer's  Guide 

D/H  CAKE  MIX  .83 
WALNUTS  CAN  .59 
JELL0  PUDDING   .30 

►  UNIVERSAL  PRODUCT  CODE  see  booklet 
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LASER  SCANNER  see  bklt 
CHRRY  TOMATO    .79 

►  ELECTRONIC  CASH  REGISTER  see  bklt 
1  CUCUMBERS      .34 

►  HANDLING  OF  UNC0DED  ITEMS  see  bklt 

►  ELECTRONIC  SCALES  see  bklt 
GREETING  CARD     .60 

►  WEIGHTS  &  MEASURES  ENFORCEM'T  see  bklt 

DELICATESSEN     1.35 
2.19b  @49/bBR0CC0  1.07 

►  SPECIAL  FEATURES  OF  COMPUTER  CHECKOUT 
SYSTEMS  see  bklt 

DRUG  4.49  T 

►  BANK  TELLER  MACHINES  see  bklt 

►  COMPUTER  TERMINALS  see  bklt 

►  CONSUMER  ISSUES  see  bklt 

►  THANK  YOU  BE  INFORMED  see  bklt 
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NBS  TECHNICAL  PUBLICATIONS 


PERIODICALS 

JOURNAL  OF  RESEARCH— The  Journal  of  Research  of  the 
National  Bureau  of  Standards  reports  NBS  research  and  develop- 
ment in  those  disciplines  of  the  physical  and  engineering  sciences  in 
which  the  Bureau  is  active.  These  include  physics,  chemistry, 
engineering,  mathematics,  and  computer  sciences.  Papers  cover  a 
broad  range  of  subjects,  with  major  emphasis  on  measurement 
methodology  and  the  basic  technology  underlying  standardization. 
Also  included  from  time  to  time  are  survey  articles  on  topics 
closely  related  to  the  Bureau's  technical  and  scientific  programs. 
As  a  special  service  to  subscribers  each  issue  contains  complete 
citations  to  all  recent  Bureau  publications  in  both  NBS  and  non- 
NBS  media.  Issued  six  times  a  year.  Annual  subscription:  domestic 
$13;  foreign  $16.25.  Single  copy,  $3  domestic;  $3.75  foreign. 
NOTE:  The  Journal  was  formerly  published  in  two  sections:  Sec- 
tion A  "Physics  and  Chemistry"  and  Section  B  "Mathematical 
Sciences." 

DIMENSIONS/NBS— This  monthly  magazine  is  published  to  in- 
form scientists,  engineers,  business  and  industry  leaders,  teachers, 
students,  and  consumers  of  the  latest  advances  in  science  and 
technology,  with  primary  emphasis  on  work  at  NBS.  The  magazine 
highlights  and  reviews  such  issues  as  energy  research,  fire  protec- 
tion, building  technology,  metric  conversion,  pollution  abatement, 
health  and  safety,  and  consumer  product  performance.  In  addi- 
tion, it  reports  the  results  of  Bureau  programs  in  measurement 
standards  and  techniques,  properties  of  matter  and  materials, 
engineering  standards  and  services,  instrumentation,  and 
automatic  data  processing.  Annual  subscription:  domestic  $11- 
foreign  $13.75. 

IMONPERIODICALS 

Monographs— Major  contributions  to  the  technical  literature  on 
various  subjects  related  to  the  Bureau's  scientific  and  technical  ac- 
tivities. 

Handbooks— Recommended  codes  of  engineering  and  industrial 
practice  (including  safety  codes)  developed  in  cooperation  with  in- 
terested industries,  professional  organizations,  and  regulatory 
bodies. 

Special  Publications— Include  proceedings  of  conferences  spon- 
sored by  NBS,  NBS  annual  reports,  and  other  special  publications 
appropriate  to  this  grouping  such  as  wall  charts,  pocket  cards,  and 
bibliographies. 

Applied  Mathematics  Series— Mathematical  tables,  manuals,  and 
studies  of  special  interest  to  physicists,  engineers,  chemists, 
biologists,  mathematicians,  computer  programmers,  and  others 
engaged  in  scientific  and  technical  work. 

National  Standard  Reference  Data  Series— Provides  quantitative 
data  on  the  physical  and  chemical  properties  of  materials,  com- 
piled from  the  world's  literature  and  critically  evaluated. 
Developed  under  a  worldwide  program  coordinated  by  NBS  under 
the  authority  of  the  National  Standard  Data  Act  (Public  Law 
90-396). 


NOTE:  The  principal  publication  outlet  for  the  foregoing  data  is 
the  Journal  of  Physical  and  Chemical  Reference  Data  (JPCRD) 
published  quarterly  for  NBS  by  the  American  Chemical  Society 
(ACS)  and  the  American  Institute  of  Physics  (AIP).  Subscriptions, 
reprints,  and  supplements  available  from  ACS,  1 155  Sixteenth  St., 
NW,  Washington,  DC  20056. 

Building  Science  Series — Disseminates  technical  information 
developed  at  the  Bureau  on  building  materials,  components, 
systems,  and  whole  structures.  The  series  presents  research  results, 
test  methods,  and  performance  criteria  related  to  the  structural  and 
environmental  functions  and  the  durability  and  safety  charac- 
teristics of  building  elements  and  systems. 

Technical  Notes— Studies  or  reports  which  are  complete  in  them- 
selves but  restrictive  in  their  treatment  of  a  subject.  Analogous  to 
monographs  but  not  so  comprehensive  in  scope  or  definitive  in 
treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final 
reports  of  work  performed  at  NBS  under  the  sponsorship  of  other 
government  agencies. 

Voluntary  Product  Standards— Developed  under  procedures 
published  by  the  Department  of  Commerce  in  Part  10,  Title  15,  of 
the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all 
concerned  interests  with  a  basis  for  common  understanding  of  the 
characteristics  of  the  products.  NBS  administers  this  program  as  a 
supplement  to  the  activities  of  the  private  sector  standardizing 
organizations. 

Consumer  Information  Series— Practical  information,  based  on 
NBS  research  and  experience,  covering  areas  of  interest  to  the  con- 
sumer. Easily  understandable  language  and  illustrations  provide 
useful  background  knowledge  for  shopping  in  today's  tech- 
nological marketplace. 

Order  the  above  NBS  publications  from:  Superintendent  of  Docu- 
ments, Government  Printing  Office,   Washington,  DC  20402. 
Order  the  following  NBS  publications— Fl PS  and  NBSIR's—from 
the  National  Technical  Information  Services,  Springfield,  VA  22161. 

Federal    Information    Processing    Standards    Publications    (FIPS 

PUB)— Publications  in  this  series  collectively  constitute  the 
Federal  Information  Processing  Standards  Register.  The  Register 
serves  as  the  official  source  of  information  in  the  Federal  Govern- 
ment regarding  standards  issued  by  NBS  pursuant  to  the  Federal 
Property  and  Administrative  Services  Act  of  1949  as  amended, 
Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  by  Ex- 
ecutive Order  1 1 7 1 7  (38  FR  12315,  dated  May  1 1 ,  1 973)  and  Part  6 
of  Title  15  CFR  (Code  of  Federal  Regulations). 

NBS  Interagency  Reports  (NBSIR)— A  special  series  of  interim  or 
final  reports  on  work  performed  by  NBS  for  outside  sponsors 
(both  government  and  non-government).  In  general,  initial  dis- 
tribution is  handled  by  the  sponsor;  public  distribution  is  by  the 
National  Technical  Information  Services,  Springfield,  VA  22161, 
in  paper  copy  or  microfiche  form. 


BIBLIOGRAPHIC  SUBSCRIPTION  SERVICES 


The  following  current-awareness  and  literature-survey  bibliographies 
are  issued  periodically  by  the  Bureau: 

Cryogenic  Data  Center  Current  Awareness  Service.  A  literature  sur- 
vey issued  biweekly.  Annual  subscription:  domestic  $35;  foreign 
$45. 

Liquefied  Natural  Gas.  A  literature  survey  issued  quarterly.  Annual 
subscription:  $30. 


Superconducting  Devices  and  Materials.  A  literature  survey  issued 
quarterly.  Annual  subscription:  $45.  Please  send  subscription  or- 
ders and  remittances  for  the  preceding  bibliographic  services  to  the 
National  Bureau  of  Standards,  Cryogenic  Data  Center  (736) 
Boulder,  CO  80303. 
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